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The  main  purpose  of  this  study  was  to  develop  criteria  by  which  it  will  be 
possible  to  qualitatively  measure  and  evaluate  the  performance  of  compilers, 
poRflihly  operating  on  different  computers,  and  possibly  having  different 
features.  To  satisfy  this  purpose,  three  technical  questions  were  studied:  (1) 

How  can  two  compilers  with  the  same  features  and  operating  in  the  same  environ- 
ment be  compared?  (2)  If  two  compilers  with  the  same  features  operate  in  dif- 
ferent environments,  how  can  their  measured  differences  in  performance  be  attri-: 
buted  to  the  environmental  differences  vs.  the  compiler  differences?  (3)  How 
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should  a compiler  buyer  deal  with  the  problem  of  evaluating  compilers  with 

special  features?  These  three  questions  were  studied  from  a point  of 
view  that  the  answers  should  help  provide  a bails  for  conducting  dollar  cost/ 
benefit  analysis  of  compilers.  In  addition,  a fourth  question  was  studied  to 
satisfy  a specific  secondary  purpose  of  the  study:  Can  analysis  of  a compiler’s 

architecture  and  algorithms  provide  a basis  for  making  valid  judgments  about  the 
performance  that  should  be  expected  from  a compiler? 

The  general  conclusion  from  studying  the  fourth  question  was  that  anaiy&'.'s 
of  the  internal  organization  of  a compiler  was  not  useful  in  providing  a basic 
for  compiler  evaluation.  The  study  of  the  first  question  established  criteria 
and  methodb  for  assigning  four  measures  (time  and  space  for  both  compiler  and 
object  code)  to  a compiler  which  quantitatively  define  its  performance  with 
respect  to  a typic.al"  user  program.  The  study  of  the  second  question  estab- 
lished criteria  for  defining  a "compiler  Gibson  mix",  and  established  methods 
for  using  this  "mix"  to  "equalize"  environments.  The  study  of  the  third  ques- 
tion established  contractual  methods  for  providing  a cost  component  of  cost/ 
benefit  analysis  of  special  features;  a] .-to,  several  specific  areas  for  future 
study  were  Identified  which  would  provide  needed  data  for  establishing  a basis 
for  the  benefit  side  of  such  analyses. 


* 


Technical  Evaluation 


* 1.  This  effort,  Conpiier  Performance  Criteria  and 
Measurement  Study,  was  undertaken  to  investigate  methods  of 
determining  and  evaluating  the  performance  of  compilers , 

* that  will  be  more  objective,  informative  and  reliable  than 
methods  currently  in  use. 
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2.  At  present,  conpiier  performance  measurements  are  taken 
in  terms  of  cards  per  minute  and  machine  instructions,  per 
source  statement  without  any  scientific  basis  for  the 
contents  of  the  card,  the  size,  type  or  complexity  of  the 
statement,  or  the  planned  environment  of  the  conpiier. 

3.  This  effort  defines  the  methodology  by  which  compiler 
performance  may  be  objectively  measured  and  compared  to 
other  compilers , including  factors  such  as  appli. cation  and 
environment. 

4.  This  effort  establishes  the  criteria  necessary  for  the 
evaluation  of  compilers  that  will  insure  that  the  compiler 
selected  for  a particular  use  is  the  most  eff5.cient  compiler 
that  will  meet  the  requirements.  The  methods  by  which  test 
program;  are  developed  and  the  measured  results  analyzed  are 
specified.  Guide  lines  for  data  to  be  collected,  and  methods 
for  collecting  the  data  are  presented  for  the  conpiier  and 
user  profiles  involved.  Methods  developed  in  this  effort 
will  be  valuable  ir.  future  procurements  of  compilers  in 
insuring  cost  effectiveness . 
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Project  Engineer 
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SUMMARY 

The  main  purpose  of  this  study  was  to  develop  criteria  by  which 
it  will  be  possible  to  qualitatively  measure  and  evaluate  the  performance 
of  compilers,  possibly  operating  on  different  computers,  and  possibly 
having  different  features.  To  satisfy  this  purpose,  three  technical 
questions  were  studied:  (1)  How  can  two  compilers  with  the  same  features 
and  operating  in  die  same  environment  be  compared  ? (2)  If  two  compilers 
with  the  same  features  operate  in  different  environments,  how  can  their 
measured  differences  in  performance  be  attributed  to  the  environmental 
differences  vs,  the  compiler  differences  ? (3)  How  should  a compiler 

buyer  deal  with  the  problem  of  evaluating  compilers  with  different  special 
features  ? These  three  questions  were  studied  from  a point  of  view  that 
the  answers  should  help  provide  a basis  for  conducting  dollar  cost/benefit 
analysis  of  compilers.^  In  addition,  a fourth  quesuion  was  studied  to 
satisfy  a^specific  secondary  purpose  of  the  study:  Can  analysis  of  a 
compiler's  architecture  and  algorithms  provide  a basis  for  making  valid 
judgements  about  the  performance  that  should  be  expected  from  a 
compiler  ? 

In  studying  the  four  til  question,  fourteen  functional  elements  of 
a compiler  were  identified  and  described.  A one-pass  architecture 
involving  eight  elements  and  a thirteen  phase  multi-pass  architecture 
involving  thirteen  elements  were  developed  to  illustrate  the  extremes 
of  architectural  choice  in  conipiler  design.  Four  elements  were  studied 
in  detail:  table  look-up,  parsing,  optimization,  and  code  generation. 

The  general  conclusion  reached  from  studying  the  fourth  question  was  that 
analysis  of  a compiler 's  internal  organization  was  not  useful  in  providing 
a basis  for  compile r evaluation. 

The  first  question  was  studied  in  terms  of  establishing  criteria 
for  defining  elements  of  a User  Profile  in  terms  of  specific  categories 
of  the  language  on  which  a compiler  operates.  A User  Profile  is  specified 
quantitatively  as  the  fractions  of  a "typical"  user  program  that  are  in 
the  form  of  specific  language  elements.  The  same  language  elements  can 
also  be  used  to  establish  a Compiler  Performance  Profile;  which  describes 
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quantitately  how  a compiler  performs  with  respect  to  each  language 
element.  This  profile  consists  of  (generally)  four  measures  for  each 
language  element:  time  and  space  for  both  compiler  and  object  code. 
Criteria  were  established  for  writing  test  programs  for  each  language 
element  to  be  used  in  maldng  these  four  measurements.  A method  was 
developed  for  combining  the  User  Profile  and  Compiler  Performance 
Profile  to  produce  a Compiler  Evaluation  Profile.  This  profile  consists 
of  the  four  quantitative  measurements  of  a compiler's  performance  with 
respect  to  a 1 'typical' ■ user  program. 

The  study  of  the  second  question  established  criteria  for  defining 
a "compiler  Gibson  mix".  This  "mix"  defines  how  well  a computer/ 
operating  system  supports  the  activity  of  compiling.  The  basis  for 
defining  this  "mix"  is  the  establishing  of  a "typical"  Compiler  Demand 
Profile.  This  profile  is  similar  to  a User  Piofile,  but  describes  a 
compiler  as  a user  of  the  language  in  which  the  compiler  is  written. 

Two  such  profiles  were  established  during  the  study:  one  for  an  AED 
compiler  and  one  for  a J3B  compiler.  These  two  profiles  turned  out  to 
be  very  similar  and  provided  the  basis  of  an  example  of  a "compiler 
Gibson  mix"  which  was  developed  during  the  study.  Methods  were  also 
established  for  using  the  "mix"  to  "equalize"  environments  as  an  answer 
to  the  second  question. 

The  third  question  was  studied  only  to  a limited  extent.  A 
contractura1  basis  for  the  cost  side  of  cost/benefit  analysis  of  special 
features  was  developed.  Also,  several  specific  areas  were  identified 
for  future  study  which  would  provide  data  needed  for  establishing  a basis 
for  tho  benefit  side  of  such  analysis. 
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CHAPTER  1 
INTRODUCTION 


1.  Background 

Compiler  performance  is  one  of  the  most  critical  aspects  in 
today's  software  development  process , and  the  admitted  lack  of  scientifically 
based,  useful  evaluation  criteria  poses  frustrating  problems  for  buyers 
and  sellers  alike.  For  the  Air  Force,  the  value  of  having  standard  and 
fair  techniques  for  evaluating  compilers  is  clear: 

• It  will  help  to  insure  selection  of  compilers  for  Air 
Force  use  that  really  meet  Air  Force  needs. 

• It  will  help  to  insure  that  when  buying  a new  compiler, 
the  Air  Force  will  get  value  for  its  money,  by 
providing  solid  acceptance  test  criteria. 

• It  will  help  to  prevent  and  resolve  disagreements  about 
the  performance  quality  of  a particular  compiler  by 
highlighting  the  reasons  for  disagreement. 

There  are  countless  opportunities  for  consciously  and  uncon- 
sciously biasing  an  evaluation  of  compiler  performance.  It  is  no  wonder 
that  different  evaluators  reach  widely  varying  conclusions.  What 
constitutes  a fair  measurement  of  a compiler's  performance?  What 
are  the  sources  of  bias,  and  how  can  they  be  eliminated? 

These  questions  provide  the  point  of  departure  for  the  study 
described  in  this  report.  At  present,  compiler  efficiency  measurements 
are:  commonly  expressed  in  terms  of  cards  per  minute  and  machine 
instructions  per  source  statement.  These  expressions  at  best  are 
inaccurate.  When  confronted  with  a measurement  expressed  in  cards 
per  minute  one  must  determine  what  is  included  in  this  minute,  what 
clock  is  used,  if  I/O  and  operating  system  time  is  included,  how  many 
statements  are  on  a card,  and  the  complexity  of  each  statement. 

Similarly,  when  a measurement  is  expressed  in  terms  of  machine 
instructions  produced  per  source  statement,  it  is  necessary  to  ask  how 
complex  the  statement  was,  what  machine  instructions  were  necessary 
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to  perform  the  function  of  the  source  statement,  and  how  many  times  each 
instruction  is  executed.  The  inaccuracies  caused  by  expressing  per- 
formance in  these  terms  has  made  possible  widely  differing  claims  of 
performance,  or  the  lack  of  performance,  by  different  individuals  for  the 
same  compiler.  Using  the  criteria  of  cards  per  minute  and  instructions 
per  statement  to  measure  performance,  it  is  possible  for  the  producer 
of  a compiler  to  back  up  very  optimistic  performance  claims  simply  by 
properly  arranging  a test  program. 

As  will  be  seen,  this  report  presents  a basis  for  defining  a 
methodology  for  evaluating  the  performance  of  compilers,  together  with 
supporting  data,  which  justifies  the  conclusion  that  the  methodology  will 
be  significantly  more  objective,  fair,  informative,  and  reliable  than 
methods  currently  in  use. 

2.  Purpose  of  the  Study 

In  considering  the  objectives  to  be  sought  in  performing  the 
present  study,  two  distinct  points  of  view  were  taken  into  account.  The 
first  point  of  view  required  the  identification  of  specific  technical 
objectives.  These  objectives  were,  for  the  most  part,  spelled  out 
explicitly  in  the  statement  of  work  for  the  project.  The  second  part 
view  looked  beyond  the  technical  goals  toward  eventual  application  of 
the  results  of  the  study.  These  application  objectives  provided  insights 
which  were  useful  in  establishing  an.  appropriate  operational  organization 
of  the  study  activities. 

The  result  of  the  organizational  effort  was  to  seek  a basis  for 
answering  a small  number  of  specific,  well  defined,  technical  questions. 
Here  the  intent  was  to  separate  the  varied  aspects  of  the  numerous 
technical  problems  to  be  explored  into  a few  clearly  defined  questions. 

The  combined  answers  to  these  technical  questions  would  provide  the 
basis  for  fulfilling  th«  technical  objectives. 

The  technical  objectives  and  the  application  objectives  are  dis- 
cussed bc)ow.  The  organization  of  the  study  into  four  specific  technical 
questions  is  d.scuosed  briefly  in  Section  3,  and  in  greater  detail  in 
Chapter  2. 
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Technical  Objectives.  7.‘he  overall  technical  objective  of  this 
study  was  to  develop  criteria  by  which  it  will  be  possible  to  qualitatively 
measure  and  evaluate  compiler  performance.  These  measurements 
should  make  possible  valid  performance  comparisons  of  different  com- 
pilers on  different  machines.  If  the  results  of  the  measurements  are 
weighted  appropriately,  then  it  should  be  possible  to  equalize  the 
environment  in  which  the  compiler  is  being  measured  with  other  environ- 
ments in  which  similar  compilers  might  be  measured.  This  "equalization" 
of  environments  should  take  into  account  factors  such  as  memory  size, 
processor  speed,  instruction  set,  and  operating  system  support. 

Once  an  "equalization"  of  environmental  differences  has  been 
performed,  it  is  desired  that  criteria  be  established  for  properly  taking 
into  account  other  factors  such  as  the  type  of  compiler  being  tested 
(e.g.  production,  debugging,  etc.),  characteristics  of  the  machine  and/ 
or  operating  system  for  which  the  compiler  was  designed,  and  other 
features  of  the  compiler  that  might  adversely  effect  the  performance  of 
the  compiler  while  producing  an  overall  savings  to  the  user.  Other 


factors  to  be  taken  into  account  ar.e  the  effects  on  compiler  performance 
caused  by  including  in  a compiler  functions  such  as  optimization  and 
debugging  aids.  Here  it  is  desirable  to  determine  a method  whereby 
the  final  performance  value  calculated  for  a compiler  can  include  an 
appropriately  weighted  component  so  as  to  negate  the  compromises  in 
compiler  efficiency  made  necessary  by  including  these  functions. 

Thus,  the  overall  technical  objective  can  be  summarized  as 
follows.  It  is  desired  to  determine  criteria  by  which  the  performance 
of  a compiler  can  be  measured  and  compared  to  that  of  other  compilers. 
In  particular,  the  criteria  shall  include  factors  such  as  speed,  size, 
ease  of  use  and  maintenance,  and  efficiency  of  generated  code.  Further- 
more, the  result  of  using  the  criteria  obtained  in  the  study  should 
reduce  the  range  of  values  obtained  when  different  individuals  measure 
the  performance  of  any  given  compiler. 
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A specific  secondary  technical  objective  was  identified  for  this 
study.  This  objective  was  to  determine  whether  or  not  knowledge  of 
the  architecture  and  algorithms  used  in  a compiler  might  provide  a 
basis  for  making  valid  judgements  about  the  performance  that  should 
be  expected  from  a compiler,  independent  of  actually  measuring  per- 
formance by  means  of  test  runs,  etc.  For  example,  car.  a useful 
generalization  be  made  about  an  algorithms  to  the  effect  that  it  is  most 
efficient  for  the  particular  language  and/or  application  for  which  it  is 
used,  or  that  the  complexity  of  the  algorithm  is  wrong  for  that  of  the 
language  and/or  application. 
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With  respect  to  parsing  schemes  and  table  searching  methods 
in  particular,  a specific  technical  objective  was  to  determine: 

• If  there  is  a particular  parsing  scheme  that  is  most 
efficient  for  all  languages  and  user  types,  or  is  each 
language  better  suited  by  a unique  parsing  scheme. 

• If  there  is  a relationship  between  table  searching 
methods  and  the  type  of  language  which  is  being 
compiled. 

In  addition  to  these  two  major  functional  elements  of  a compiler 
(parsing  and  table  look-up),  two  other  elements  (code  generation  and 
optimization)  were  also  reviewed  with  the  objective  of  seeking  useful 
generalizations.  Also,  an  analysis  of  architectural  choices  in  compiler 
design  was  made.  With  this  context  in  mind,  it  is  convenient  to  sum- 
marize briefly  here  the  major  conclusions  resulting  from  this  part  of 
the  study. 

• With  respect  to  compiler  architectures,  one-pass 
compilers  are  faster  and  larger  than  multi-pass  compilers. 

• Multi-pass  compilers  permit  more  extensive  optimizations, 
and  therefore  can  produce  more  efficient  object  code. 

• Choices  of  algorithms  for  parsing  and  code  generation 
are  generally  made  for  other  than  performance  reasons. 
Generally,  the  reasons  relate  to  cost  of  development  of 
the  compiler. 
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• Some  generalizations  on  the  relative  efficiency  of  table 
look-up  algorithms  are  possible,  but  such  generalizations 
are  mainly  related  to  specific  internal  architectural 
purposes  for  the  table  rather  than  external  factors  such 
as  die  language  being  compiled. 

• Optimization  methods  are  highly  varied,  and  no  useful 
quantitative  generalization  was  found  which  could  relate 
compiler  performance  and  object  code  quality  for  a 
particular  individual  or  class  of  optimizations. 

In  view  of  the  above  paucity  of  useful  generalizations  that 
resulted  from  the  study  of  architectures  and  algorithms,  it  is  clear 
that  a different  approach  is  necessary  to  establish  the  desired  criteria 
to  satisfy  the  technical  objectives  of  the  proposal.  The  approach  taken 
is  discussed  briefly  in  Section  3,  and  in  greater  detail  in  Chapter  2. 


Application  Objectives.  Given  that  criteria  could  be  determined 
for  compiler  evaluation  as  discussed  above,  what  application  might  be 
made  of  these  criteria?  Answering  this  question  provided  insights 
that  were  useful  in  organizing  the  activities  of  the  study.  These 
activities  are  discussed  briefly  in  Section  3 and  in  greater  detail  in 
Chapter  2.  The  answer  to  the  question  is  summarized  below. 

The  criteria  to  be  established  by  the  study  will  be  useful  for  the 
following  tasks: 

• Selecting  the  best  performing  compiler  from  among  a 
number  of  off-the-shelf  compilers. 

• Preparing  RFP's  for  compilers  and  providing  the  basis 
for  reliable  performance  acceptance  testing  of  the 
delivered  product. 

• Provide  useful  assistance  in  choosing  computer  hardware 
and  compiler  combinations  as  a package. 

• Provide  useful  assistance  in  choosing  computer  hardware 
where  compilers  are  to  be  purchased  separately. 


With  these  application  objectives  in  mind,  it  becomes  clear  that 
the  criteria  to  be  established  to  satisfy  the  technical  objectives  discussed 
above  must  (at  least  in  principal)  be  translatable  into  a common  unit  of 
value  . The  obvious  unit  of  value  that  comes  to  mind  is  the  dollar. 
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Consequently,  it  became  an  identified  objective  of  the  study  to  establish 
criteria  which  could  provide  the  basis  of  dollar  cost/benefit  analysis 
of  a compiler.  This  means  that  measurements  to  be  taken  of  compiler 
performance  should  ultimately  be  translatable  into  a dollar  value  for 
the  performance  benefit  of  the  compiler.  The  approach  taken  in  this 
study  is  specially  directed  toward  this  objective. 

Implicit  in  the  above  observation  is  that  a better  basis  for 
establishing  the  dollar  cost  of  a compiler  is  needed.  In  choosing  off- 
the-shelf  compilers,  its  price  tag  is  an  adequate  cost  measure.  However, 
in  preparing  RFP's,  the  vendor  must  be  given  in  incentive  to  produce 
a better  performing  compiler  than  minimum  specifications.  These  cost 
and  incentives  issues  are  beyond  the  3cope  of  the  present  study.  However, 
the  criteria  for  evaluating  performance  might  be  a suitable  basis  for 
eventually  establishing  appropriate  incentives  in  procuring  compilers, 
once  sufficient  experience  in  their  use  has  accumulated. 

3.  Technical  Questions  Studied 

In  this  section  a brief  discussion  is  presented  of  the  spex-.ific 
technical  questions  whose  answers  were  sought  as  the  basis  for  fulfilling 
the  technical  objectives  of  the  study.  The  reasons  for  choosing  these 
questions,  and  how  these  questions  determined  the  specific  activities  of 
the  study  are  discussed  in  Chapter  2. 

Four  technical  questions  were  pursued.  These  questions  are 
conveniently  organized  into  two  groups.  The  first  group  consists  of 
the  following  single  question  which  constitues  the  basis  for  fulfilling 
the  specific  secondary  technical  objective  discussed  in  Section  2: 

• Can  analysis  of  a compiler's  architecture  and 
algorithms  provide  a basis  for  making  valid 
judgements  about  the  performance  that  should 
be  expected  from  a compiler  ? 

We  will  refer  to  this  question  briefly  as  the  "architecture /algorithms 
question". 
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The  second  part  consists  of  three  questions  which  jointly  provide 
the  basis  for  fulfilling  the  overall  teclinical  question  discussed  in 
Section  2,  These  questions  are  listed  below, 

« How  cam  two  compilers  w:.th  the  same  features  and 
operating  in  the  same  environment  be  compared  ? 

• If  two  compilers  with  the  same  features  operate  in 
different  environments,  how  can  their  measured 
differences  in  performance  be  attributed  to  the 
environmental  differences  vs.  the  compiler 
differences  ? 

» How  should  a compiler  buyer  deal  with  the  problem 
of  evaluating  compilers  with  different,  special 
features  ? 

These  three  questions  will  be  briefly  referred  to  respectively  as: 

• The  "same  environment  question", 

• The  "environment  equalizing  question",  and 

• The  "special  features  question". 

It  should  be  noted  that,  the  first  question  is  directly  applicable 

to  the  application  objective  of  selecting  among  off-the-shelf  compilers 
(provided  that  these  compilers  have  similar  features).  Furthermore, 

i 

the  question  specifically  applies  to  the  overall  technical  question  once 
the  environmental  contributions  have  been  "equalized"  and  appropriate 
weights  for  special  features  have  been  calculated. 

The  second  question  is  specifically  aimed  at  the  application 
objective  of  assisting  in  hardware  selection  where  compilers  are  to  be 
procured  separately.  Furthermore,  this  question  specifically  applies 
to  the  overall  technical  question  in  that  its  answer  provides  the  basis 
for  "equalizing"  environments. 

The  third  question  is  specifically  aimed  at  the  technical  objective 
of  calculating  appropriate  weights  for  making  compensations  in  overall 
performance  values  calculated  for  compilers  with  different  special 
features. 
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4.  Organization  of  the  Final  Report 

Chapter  2 presents  a detailed  discussion  of  how  the  technical 
questions  studied  contribute  to  fulfilling  technical  and  application 
objectives,, 

Chapters  3,  4,  5,  6,  and  7 respectively  present  analyses  of 
architectural  choices  in  compilers,  and  algorithms  used  for  table 
look-up,  parsing,  optimization,  and  code  generation.  These  analyses 
comprise  the  report  on  the  study  of  the  architecture /algorithms 
question. 


Chapters  8 and  9 provide  a basis  for  answering  the  same  environ- 
ment question.  Chapter  8 provides  a detailed  overview  and  technical  frame- 
work, and  Chapter  9 specifically  establishes  methods  of  preparing  test 
programs  which  would  establish  useful  compiler  performance  measures. 


Chapters  10,  11,  and  12  provide  a basis  for  answering  the 
environment  equalizing  question.  Chapter  10  describes  the  methods 
that  can  be  used  to  measure  environments  in  terms  of  a "compiler 
Gibson  mix".  That  is,  standard  tests  are  described  which  can  be  applied 
to  different  environments  to  determine  their  relative  efficiency  in 
supporting  compi'.er  activities,  and  thus  providing  "equalization"  factors 
for  the  environments.  Chapters  11  and  12  present  experimental  data 
which  provide  the  basis  of  establishing  a "compiler  Gibson  mix". 

Chapter  13  discusses  a basis  for  seeking  an  answer  to  the  special 
feature  question.  The  study  of  this  question  quickly  led  to  the  conclusion 
that  a great  deal  c.f  work  beyond  the  scope  of  the  present  study  would  be 
required  in  order  to  establish  criteria  to  answer  this  question  in  an 
adequate  manner.  Consequently,  the  study  wa3  limited  to  identifying 
specific  areas  of  possible  future  study  that  would  contribute  to  providing 
an  adequate  answer. 

Chapter  14  summarizes  the  conclusions  reached  in  the  study. 
Conclusions  are  generally  included  in  the  separate  chapters  where 
appropriate,  and  Chapter  14  presents  an  organized  list  of  these  con- 
clusions with  appropriate  cross  references  to  other  sections  of  the 
report. 
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Chapter  15  presents  recommendations  which  appear  appropriate 
in  the  light  of  the  results  of  the  study.  Specifically,  these  recommendations 
identify  areas  requiring  further  study,  and  summarize  the  specific  pro- 
cedures constituting  a standardized  methodology  for  evaluating  compilers 
in  different  environments  with  different  special  features  which  were 
developed  in  the  study. 
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CHAPTER  2 

OVERVIEW  OF  TECHNICAL  QUESTIONS 
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1.  Introduction 

Section  2 of  this  chapter  introduces  the  basic  technical  concepts  on 
which  the  study  was  based.  The  concepts  are  discussed  briefly  in  Section  2 
and  in  further  detail  in  other  sections  of  this  chapter.  It  is  convenient  to 
organize  the  concepts  i;.io  two  broad  catagories: 

« Concepts  related  to  the  establishing  of  a canonical 

representation  of  users,  environments,  and  compilers. 

© Concepts  related  to  catagorizing  the  factors  which  influence  the 
performance  of  compilers  in  measurable  terms. 

The  first  category  consists  of  a number  of  profiles  and  "Gibson 
mixes".  Profiles  represent  a user  or  a compiler  in  terms  of  elements  of  a 
high  level  language,  such  as  AED,  or  the  source  language  on  which  a 
compiler  to  be  evaluated  performs  its  compilation  function,  or  in  terms  of 
performance  factors.  A "Gibson  mix"  is  a representation  of  a collection  of 
programs  in  terms  of  which  a compiler /ope rating  system  environment  can 
be  measured.  The  result  of  such  a measurement  provides  a quantitative 
statement  of  the  degree  to  which  such  an  environment  supports  the  functions 
of  the  collection  of  programs. 

The  second  category  establishes  a complete  organization  of  factors 
affecting  performance.  The  organization  consists  of  five  components 
which  are  introduced  briefly  in  Section  2,  and  are  discussed  in  detail  in 
Section  7. 

Sections  3,  4,  5,  and  6 respectively  present  discussions  of  the 
architecture  /algorithms  question,  the  same  environment  question,  the 
environment  equalizing  question,  and  the  special  features  questions.  For 
the  architecture  /algorithms  question,  the  discussion  consists  of  a general 
introduction  to  Chapters  3,  4,  5,  6,  and  7 in  which  detailed  discussions  o£ 
algorithm  choices  and  algorithms  for  four  compiler  functions  are  discussed. 

For  the  remaining  three  questions,  the  discussions  in  their  respective  sections 
provide  an  overview  of  the  approach  taken  in  this  study  to  explore  the  question, 
and  a brief  summary  of  how  the  study  of  the  questions  contributes  to  establishing 
a basis  for  cost/benefit  analysis  of  compilers. 
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2.  Technical  Concepts 

This  section  introduces  the  technical  concepts  on  which  the  study  was 
based.  Each  of  the  concepts  relate  to  repr?«enting  users,  environments 
and  compilers,  and  each  is  discussed  in  a separate  sub-section,  The 
discussion  includes  a description  of  how  these  concepts  interrelate.  The 
five  factors  which  influence  performance  are  introduced  in  the  first  sub- 
section of  this  section. 

Factors  that  influence  compiler  performance.  Below  is  a brief 
introduction  to  the  five  classes  of  factors  that  influence  the  measureable 
performance  of  a compiler.  These  factors  are  discussed  in  further  detail 
in  Section  7. 
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1.  Directly  Measureable  Factors 

Factors  which  define  performance.  (Time  and  space  for  both 
compiler  and  object  code.  ) 

2.  Direct  Internal  Factors 

Factors  internal  to  the  compiler  (architecture  and  algorithms) 
which  directly  affect  performance  as  measured. 

3.  Direct  External  Factors 

Factors  external  to  the  compiler  (environmental  factors  such 
as  host  machine  and  operating  system,  etc.  ) which  directly 
affect  performance  as  measured. 

4.  Indirect  Interna]  Factors 

Factors  which  contribute  io  the  "value"  of  a compiler  (special 
features)  but  which  cannot  be  directly  measured  in  terms  of 
performance  as  measured. 

5.  Indirect  External  Factors 


Factors  which  define  how  the  compiler  is  to  be  used  and  thereby 
indicate  the  relative  importance  of  the  factors.  In  combination, 
these  factors  define  the  measured  performance  of  a compiler 
with  respect  to  a "typical"  source  language  program. 
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User  Profile.  A User  Profile  defines  how  a user's  application 
programs  make  use  of  the  various  elements  and  constructions  of  a language 
It  is  specified  quantitatively  as  the  fractions  of  all  the  elements  or  constructions 
of  a language  in  a "typical"  user  program  which  appear  in  the  form  of  each 
element  or  construction.  Chapter  8 presents  a description  of  the  language 
elements  which  might  be  used  as  a basis  for  defining  User  Profiles. 
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Two  different  User  Profiles  are  meaningful.  A static  User  Profile 
counts  each  occurrence  of  a language  element  in  the  user's  collection  of 
applicition  programs  equally.  A dynamic  User  Profile  weights  each 
occurrence  with  the  relative  frequency  with  which  the  occurrence  is 

executed  in  normal  use  of  the  collection  of  programs.  ! 

i 

i 

Compiler  Performance  Profile.  A Compiler  Performance  Profile  i 

defines  how  well  a compiler  handles  each  of  the  language  elements  and  j 

constructs  in  terms  of  which  User  Profiles  are  defined.  Each  element  is  J 

assigned  four  (or  sometimes  two)  performance  measures.  These  measures 
are  described  above  as  the  "directly  measurable  factors.  " j 

Compiler  Demand  Profile.  A Compiler  Demand  Profile  defines  how  j 

the  source  code  in  which  a compiler  is  written  makes  use  of  the  various  j 

elements  and  constructions  of  that  language.  It  is  specified  quantitatively  j 

in  the  same  manner  as  a User  Profile.  Both  static  and  dynamic  Compiler  j 

Demand  Profiles  are  meaningful  , as  in  the  case  of  User  Profiles.  j 

Compiler  Evaluation  Profile.  A Compiler  Evaluation  Profile  defines  ' 

how  well  a compiler  performs  on  a "typical"  user  program.  It  is  specified  ' 

quantitatively  by  four  quantities,  one  for  each  of  the  four  "directly  measur-  ^ 

able  factors"  described  above.  It  is  calculated  by  taking  a weighted  sum  of 
the  four  evaluation  factors  for  all  elements  comprising  a Compiler  Perform- 
ance Profile.  The  weights  used  for  generating  compiler  space  and  time  per- 
formance measures  are  the  static  User  Profile  weights,  and  the  dynamic 
User  Profile  weights  are  used  for  generating  the  object  code  measures. 

If  additional  administrative  information  is  taken  into  account,  then 
a number  of  useful  dollar  valuations  can  be  assignee  o a compiler  once  its 
compiler  evaluation  profile  has  been  calculated.  These  considerations  are 
discussed  further  in  Section  4 of  Chapter  8. 

"Compiler  Gibson  mix".  A "compiler  Gibson  mix"  defines  how  well  j 

a computer /ope rating  system  environment  supports  the  activity  of  compiling.  , 

i 

An  example  of  how  a ' compiler  Gibson  mix"  might  be  defined  is  presented  ! 

in  Chapter  10.  This  example  is  based  on  two  static  Compiler  Demand  ’ 

Profiles  generated  during  this  study,  one  for  an  AED  compiler  and  one  for  j 

a J3B  compiler.  ’ 

j 

11 
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"User  Gibson  mix".  A "user  Gibson  mix"  defines  how  well  a 
computer /operating  system  environment  supports  the  collection  of  user 
application  programs  which  will  normally  run  in  an  environment.  A "Gibson 
mix"  for  a computer  has  in  the  past  been  defined  for  such  applications 
categories  as  COBOL  applications.  These  "mixes"  are  based  on  specifying 
the  relative  importance  ox  different  instructions  and  addressing  modes  of  a 
computer.  It  is  suggested  in  Chapter  6 that  a "user  Gibson  mix"  could 
alternatively  be  developed  using  the  methods  of  Chapter  10  for  generating  a 
"compiler  Gibson  mix.  " Whereas  a "compiler  Gibxon  mix"  is  based  on  a 
Compiler  Demand  Profile,  the  "user  Gibson  mix"  would  be  based  on  a 
dynamic  User  Profile. 

3.  Overview  of  the  Architecture /Algorithms  Question 

In  Chapter  3,  fourteen  fuctional  elements  of  a compiler  are  described. 
An  architecture  is  described  for  a one-pass  compiler  using  eight  of  these 
elements,  and  an  architecture  for  a multi-pass  compiler  is  described 
involving  thirteen  of  the  elements.  The  multi-pass  architecture  involves 
thirteen  phases  in  order  to  demonstrate  an  extreme  design  directed  toward 
minimizing  space.  This  architecture  also  demonstrates  the  wide  range  of 
multi-pass  architectures  that  are  possible  by  means  of  recombining  the 
twelve  phases  into  a smaller  number. 

Four  of  the  twelve  functions  are  discussed  in  great  detail  in 
Chapters  4,  5,  6,  and  7.  The  functions  discussed  in  these  chapters  are 
table  look-up,  parsing,  optimization,  and  code  generation  respectively. 
Discussed  are  four  categories  of  table  look-up  algorithms,  four  categories 
of  parsers,  two  broad  categories  of  optimization  techniques  (involving  a total 
of  twenty-eight  distinct  optimizations),  and  three  types  of  code  generators. 

The  major  conclusion  reached  from  the  study  of  the  architecture/ 
algorithms  question  is  that  knowledge  of  these  aspects  of  a particular 
compiler  is  not  useful  in  evaluating  the  usefulness  of  the  compiler. 

(A  summary  of  these  conclusions  is  presented  in  Chapters  1 and  14.  ) 
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4.  Overview  of  the  Same  Environment  Question 

The  full  statement  of  the  same  environment  question  is  repeated 

below. 

How  can  two  compilers  with  the  same  features  and 
operating  in  the  same  environment  be  compared? 

Approach.  A number  of  test  programs  are  created  which  represent 
(in  a suitable  weighted  combination)  a "typical"  program  to  be  compiled  or 
executed.  The  directly  measurable  factors  are  measured  with  respect  to 
the  test  programs,  and  the  measurements  are  suitably  combined  to  create  a 
performance  measurement  for  each  directly  measurable  factor  with  respect 
to  the  "typical"  program.  The  direct  external  factors  are  not  involved  since 
the  environments  are  identical.  Direct  internal  factors  are  not  explicitly 
considered,  because  better  algorithms  and  architectures  should  result  in 
better  performance  as  measures.  However,  knowledge  of  variety  of  these 
factors  is  necessary  in  order  to  establish  a suitable  set  of  test  programs. 
Consideration  of  indirect  internal  factors  is  avoided  by  assuming  that  the 
special  features  of  the  two  compilers  are  identical.  Indirect  external 
factors  comprise  the  User  Profile  which  determine  the  weighting  factors  to 
use  as  combining  test  program  results  into  measures  for  the  "typical" 
program. 

Basis  for  Cost/Benefit  Analysis.  Each  directly  measurable  factor 
may  be  assigned  a relative  dollar  worth.  The  performance  measures  for  a 
"typical"  program  can  then  be  used  to  assign  a dollar  benefit  difference 
between  the  two  compilers.  Cost  is  price. 


5.  Overview  of  the  Environment  Equalizing  Question 

The  full  statement  of  the  environment  equalizing  question  ic  repeated 

below. 

If  two  compilers  with  the  same  features  operate  in 
different  environments,  how  can  their  measured 
differences  in  performance  be  attributed  to  the 
environmental  differences  vs.  the  compiler 
differences  ? 

Approach.  Each  compiler  is  evaluated  as  in  the  equal  environment 
question  to  generate  performance  measures  for  a "typical"  program. 


However,  these  measures  represent  effects  of  both  direct  internal  factors 
(architecture  and  algorithms)  and  direct  external  factors  (machine  and 
operating  system).  To  separate  these  two  contributions,  generate  a 
Compiler  Demand  Profile  in  terms  of  some  suitable  elements.  This  profile 
constitutes  the  relative  use  of  the  elements  by  a "typical"  compiler.  Each 
element  should  be  represented  as  an  assembly  language  program  pro- 
grammed by  a highly  skilled  programmer  to  take  advantage  of  all  of  the 
environmental  special  features  which  could  be  exploited  by  a compiler. 

These  programs  are  then  compiled  and  executed.  The  relative  time  and 
space  for  these  Compiler  Demand  Profile  programs  can  be  combined  to  give 
an  overall  measure  of  how  well  the  computer /ope rating  system  environment 
contribute  to  possible  compiler  performance  for  compiler  time  and  space 
measures.  If  the  test  programs  used  to  represent  the  "‘ypical"  user  pro- 
gram (the  User  Profile)  are  used  instead  of  the  Compiler  Demand  Profile 
programs,  then  the  resulting  measures  should  show  how  the  computer/ 
operating  system  environment  contribute  to  object  code  time  and  space  measures. 

Basis  for  Cost/Benefit  Analysis.  The  answer  to  the  environment 
equalizing  question  will  contribute  to  improved  purchase  criteria  for: 

(1)  A package  of  compilers  together  with  computer, 
operating  system,  etc.  ; 

(2)  A computer,  operating  system,  etc.  , when 
compilers  are  to  be  purchased  separately;  and 

(3)  Writing  specifications  for  expected  performance 

of  a compiler  on  a new  computer  operating  system, 
etc.  , based  on  the  known  performance  for  a similar 
compiler  on  a different  computer,  operating 
system,  etc. 

6.  Overview  of  the  Special  Features  Question 


The  full  statement  of  the  special  features  question  is  repeated  below. 

How  should  a compiler  buyer  deal  with  the  problem  of 
evaluating  compilers  with  different  special  features? 

Approa ch.  Rather  than  attempt  the  very  difficult  allocation  of 
performance  degradation  to  the  inclusion  of  special  features  (ease  of  use  and 
ease  of  maintenance),  we  instead  recommend  that  the  benefit  of  the  feature 
be  calculated  independently  ae  a dollar  value. 
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Basis  for  Cost/Benefit  Analysis.  For  the  ease  of  use  factors,  the 
benefit  derives  from  reduction  in  number  of  debugging  compilations,  and 
related  factors.  * These  can  relatively  easily  be  assigned  a dollar  benefit 
value.  In  comparing  two  compilers,  their  differences  in  performance  may 
be  assigned  a dollar  value  as  described  above  for  the  same  environment 
question  and  the  environment  equalizing  question.  The  dollar  value  of  ease  of 
use  factors  can  then  be  added  into  the  analysis  in  a straightforward  manner. 

To  apply  this  approach  therefore  requires  research  (beyond  the  scope  of  this 
study)  on  the  psychology  of  using  ease  of  use  factors.  For  ease  of  maintenance 
factors,  the  suggested  approach  is  to  require  vendors  to  supply  option  price  for 
the  features  for  which  there  is  a clear  expectation  that  they  will  be  used.  * 

7.  Factors  That  Influence  Compiler  Performance 

With  the  above  brief  overview  of  the  three  main  technical  questions 
of  our  study  to  provide  an  understanding  of  the  overall  method  of  approach 
for  the  study,  we  present  in  this  section  a discussion  of  each  of  the  five 
categories  of  factors,  and  how  they  interact  in  effecting  the  study  of  these 
three  questions. 

Directly  measurable  factors.  The  intention  here  is  to  make  measurements 
which  in  combination  provide  a Compiler  Performance  Profile.  The  dimen- 
sions of  the  profile  should  be  such  that  a User  Profile  can  also  be  generated 
which  assigns  a relative  importance  factor  to  each  dimension.  Consequently, 
the  study  establishes  criteria  which  corresponding  to  these  dimensions, 
and  establishes  methods  of  creating  test  programs  to  be  used  in  generating 
the  Compiler  Performance  Profile. 

For  each  dimension,  a group  of  test  programs  is  generated;  for  each 
test  program,  the  following  measurements  are  taken: 

1.  Compilation  Time  - This  factor  should  be  a combination  of 
both  CPU  time  and  I/O  time.  (The  present  study  was  primarily 
based  only  on  CPU  time.  ) If  the  compiler  output  is  assembly 
language  code,  the  time  to  assemble  may  be  included. 

2.  Object  Code  Execution  Time  — This  factor  is  the  CPU 
time  required  to  execute  the  compiled  code. 


* See  discussion  on  indirect  internal  factors  in  Section  7. 
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Compiler  Space  — This  factor  is  the  amount  of  core 
(e.  g.  size  of  partition)  needed  to  compile  the  test 
program. 

Object  Code  Size  — This  factor  is  the  amount  of  core 
required  to  execute  the  test  program. 


A combination  of  the  measurements  for  the  test  programs  within  the 
group  results  in  four  summary  measures  for  the  dimension. 

Direct  internal  factors.  These  factors  are  internal  to  the  compiler 
and  directly  affect  the  values  of  the  four  measurements  indicated  above. 

Thcv  Sire! 

7 ' • Architectural  organization  of  the  compiler. 

• Algorithms  used. 

• Data  organizations  used. 

• Presence  of  special  features. 

The  approach  we  take  makes  no  attempt  to  allocate  or  distribute  perform- 
ance measurements  among  the  above  internal  factors.  Rather,  the  direct 
benefits  and/or  costs  due  to  these  factors  should  be  accounted  for  in  the 
dollar  procurement  cost  of  the  compiler  and  the  Compiler  Performance 
Profile  discussed  in  Section  2.  Since  the  relative  ease  of  maintenance  may 
depend  on  the  architecture  of  the  compiler,  and  the  ease  of  use  depends  upon 
the  inclusion  of  special  features,  certain  indirect  benefits  of  architectural 
organization  and  special  features  will  be  discussed  in  a later  sub-section  on 
indirect  internal  factors.  In  spite  of  the  fact  that  this  study  was  not  directly 
concerned  with  the  effects  of  these  factors  on  performance,  it  is  important 
that  the  breadth  of  possible  direct  internal  factors  be  taken  into  account  in 
designing  the  sets  of  test  programs.  This  means  that  potential  differences 
in  performance  between  two  compilers  due  to  their  architecture  or  algor- 
ithms should  show  up  as  differences  in  Compiler  Performance  Profiles. 

The  weights  assigned  to  these  differences,  however,  are  entirely  dependent 
on  the  User  Profiles  of  the  syntactic  elements  comprising  the  dimensions  of 
the  profiles.  (See  the  later  sub-section  on  indirect  external  factors.  ) 

Direct  external  factors.  These  factors  are  external  to  the  compiler 
and  directly  affect  the  values  of  the  four  measurements  indicated  above. 
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• Machine  Configuration. 

• Machine  Speed. 

• Machine  Instruction  Set. 

• Machine  Instruction  Word  Format. 

• Operating  System 

• I/O  Interface. 

• I/O  Support  Software. 

« Linker /Loader /Compilation  Unit  Format. 

• Inter-Module  Interface  Standard. 

• Parameter  Passing  Standard. 

a Error  Handling  Standard. 

• Assembly  Language /Assembler  Requirements.  t 

i 

Consider  two  compilers  with  the  same  architecture,  algorithms,  data  ' 

organization,  and  features  which  are  to  run  in  different  environments  * 

(i.e.  different  hardware  and/or  operating  systems).  One  would  expect 
differences  in  performance  due  to  the  above  factors.  If  it  is  necessary  to  i 

compare  two  compilers  which  have  both  different  internal  factors  and 
different  external  factors,  how  does  one  attribute  the  differences  in  perform- 
ance profiles  as  to  internal  vs.  external  factors?*  The  suggested  approach  is  to  I 
develop  methods  of  constructing  a profile  cf  compilers  which  will  be  analo-  j 

gous  to  the  "COBOL  Gibson  mix"  (used  for  evaluating  the  comparative  ] 

performance  of  machines  with  respect  to  business  applications).  The  profile 
of  compiler  computational  element  usage  may  be  more  or  less  the  source  j 

for  a wide  variety  of  language  types  and  features,  or  may  be  highly  sensitive  \ 

to  such  differences.  The  study  undertakes  to  at  least  approximately  l 

determine  the  degree  of  such  variability.  Given  a profile  for  a certain  class 
of  compilers,  the  approach  recommends  that  the  profile  be  implemented  by 
good  coders  in  assembly  language  for  each  machine  under  consideration. 

The  resulting  programs  constitute  "compiler  Gibson  mix".  Given  two  environ- 
ments, the  performance  of  the  two  environments  with  respect  to  this  "mix" 
characterizes  the  overall  compiler  support  performance  factor  for  each 


* This  is  simply  a restatement  of  the  environment  equalizing  question. 
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environment  for  compiler  time  and  space  measurements.  These  factors 
would  then  constitute  the  fraction  of  combined  compiler  and  environment 
performance  for  compiler  time  and  space  as  measured  due  solely  to  environ- 
mental differences.  The  remainder  of  the  differences  in  compiler  time  and 
space  performance  as  measured  would  be  attributed  to  the  direct  internal 
factors  of  the  compilers. 

A "user  Gibson  mix"  which  characterized  the  applications  to  be  run 
could  be  used  in  a similar  manner  to  determine  the  environmental  contribu- 
tions to  the  object  code  time  and  space  performance  factors.  One  way  in 
which  such  a "user  Gibson  mix"  could  be  derived  would  be  to  use  the  test 
programs  (or  a suitable  subset)  developed  to  characterize  the  static  and 
dynamic  User  Profiles.  By  hand  coding  the  programs  into  assembly 
language,  by  a good  coder,  the  static  profile  weights  could  be  used  to 
generate  an  overall  object  code  space  factor  characterizing  the  environ- 
mental support.  By  using  the  dynamic  profile  weights,  the  overall  object 
code  time  factor  could  be  similarly  generated. 

The  present  study  of  the  direct  external  factors  is  limited  to: 

• The  approximate  determination  of  the  degree  of 
Compiler  Demand  Profile  variability. 

• Development  of  methods  for  establishing  Command 
Demand  Profiles. 

• Development  of  methods  for  measuring  the 
compiler  support  performance  profiles  of  various 
environments. 

Indirect  internal  factors.  There  are  several  factors  which  are  based 
on  architecture  and  special  features,  tnd  whose  costs  are  therefore  internal. 
However,  the  major  benefits  of  these  factors  are  external  to  the  compiler. 

Architectural  factors  may  be  present  for  such  purposes  as: 

• Portability  (changing  host  machine). 

• Retargetability  (changing  target  machine). 

• Maintenance  (bug  fixing). 

• Enhancabifity  (adding  features). 

The  suggested  approach  to  these  features  is  thaf.  the  cost/benefit  analysis 
can  be  best  handled  contractionary.  This  will  he  discussed  further  in 
Chapter  13. 
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Ease  of  use  factors  aifect  the  value  of  a compiler  by  facilitating  the 
mannc  r in  which  a compiler  can  be  used  operationally.  The  following  are  a 
list  of  such  factors: 


• Diagnostics. 

• Data  dependent  error  detection. 

• Parameter /argument  data  type  matching. 

c Syntactic  error  detection. 

• Hooks  for  traces,  breakpoints,  symbolic  debugging, 
patching,  etc. 

The  determination  of  how  the  value  of  these  factors  can  be  evaluated  is 
beyond  the  scope  of  the  present  study.  How  their  value  might  be  determined 
is  discussed  in  Chapter  13. 

Indirect  external  factors.  The  factors  which  define  how  a compiler 
is  to  be  used  are  both  external  to  the  compiler  (being  determined  by  the  user) 
and  not  directly  measurable.  The  suggested  approach  to  these  factors  is  to 
establish  a set  of  language  elements  in  terms  of  which  a User  Profile  can  be 
ascertained.  This  profile  will  assign  to  each  element  a weight  which  will 
correspond  to  the  relative  importance  the  element  has  in  the  collection  of 
user  application  programs.  For  each  element,  one  or  more  test  programs 
can  be  written  which  when  compiled  and  executed  generate  the  four  direct 
measures  of  compiler  performance  with  respect  to  these  measurements. 
Section  5 of  Chapter  8 presents  an  organized  list  of  language  elements 
which  could  provide  the  basis  of  establishing  User  Profiles.  How  test 
programs  might  be  prepared  to  measure  a compilers  performance  with 
respect  to  these  elements,  thereby  establishing  a Compiler  Performance 
Profile,  is  described  in  Chapter  9. 
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CHAPTER  3 

ARCHITECTURAL  CHOICES  IN  COMPILER  DESIGN 


1.  Overview 

Trade-off  factors.  In  designing  a compiler,  an  architecture  is 
chosen  which  balances  a number  of  design  objectives.  The  trade-off 
factors  normally  taken  into  account  in  choosing  an  architecture  are  the 
following: 

• Compiler  speed 

• Compiler  size  (including  work  space) 

• Object  code  speed 

• Object  code  size 

• Retargetability 

• Portability 

• Ease  of  maintenance 

• Debugging  features 

• Cost  of  development 

Elements  of  compilers.  Thus,  a compiler  architecture  can  be 
regarded  as  the  organization  of  the  several  functional  elements  required 
to  perform  the  compiling  of  a source  program.  These  functional  elements 
will  be  described  briefly  in  Section  2.  For  the  purposes  of  the  overview, 
they  are  listed  below  with  short  descriptive  phrases: 

• Lexical  analysis  --  forms  lexemes. 

• Table  look-up  --  maps  lexemes  to  symbols. 

• Declaration  processing  --  assigns  types  to  symbols, 

• Parsing  --  identify  groups  of  symbol  strings. 

• *Tree  building  --  organizes  groups  into  tree  structure, 

• *#*Set/used  analysis  --  identifies  where  variables  are  set 
or  used. 

• *#*Flow  analysis  --  identifies  straight  line  executable 
sequences . 
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• ***Giobal  machine  independent  optimization  --  restructures  tree. 

• Storage  allocation  --  maps  variables  onto  storage  locations. 

• Register  allocation  --  maps  variables  onto  hardware  registers. 

• ^Machine  independent  code  generation  --  walks  tree  and 
maintains  state  information. 

• Machine  dependent  code  generation  --  outputs  object  code. 

• **Peephole  object  code  post-processing  --  modifies  object 
code  locally. 

• ***General  object  code  post-processing  --  modifies  object 
code  globally. 

Note:  Those  functional  elements  flagged  with  a single  asterisk  (*)  are 

used  in  multi-pass  compilers  to  facilitate  information  maintenance 
between  phases  (passes)  of  the  compilation.  The  single  element 
flagged  with  two  asterisks  (#*)  is  used  only  within  a one-pass 
architecture  for  optimization  purposes,  i. e. , to  improve  object 
code  quality.  Those  elements  flagged  with  three  asterisks  (***) 
are  only  used  in  multi-pass  compilers  for  a variety  of  optimization 
purposes.  (See  Chapter  6.) 

Interactions  among  trade-off  factors.  Let  us  now  consider  how 
the  trade-off  factors  influence  compiler  architecture.  Compiler  and 
object  code  speed  and  size  constitute  the  four  basic  performance  measures 
considered  in  the  study.  Compiler  size  trades -off  with  compiler  speed 
by  means  of  overlaying  and  one-pass  vs.  multi-pass  design  considera- 
tions. Object  code  speed  and  size  generally  both  improve  together  at 
the  cost  of  compiler  speed  by  means  of  various  optimization  techniques. 

Retargetability  does  not  interact  very  strongly  with  the  performance 
measures,  but  rather  interacts  for  the  most  part  in  the  ease  of  maintenance 
and  cost  of  development.  Retargetability  is  generally  obtained  by  an 
appropriate  choice  of  the  method  to  be  used  for  implementing  the  machine 
independent  part  of  the  code  generator.  (See  Chapter  7.  ) 

Portability  interacts  somewhat  with  compiler  speed  and  size 
in  that  it  is  achieved  by  minimizing  that  part  of  the  compiler  implemented 
in  assembly  language.  The  assumption  here  is  that  assembly  language 
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implementations  are  generally  more  efficient  than  high  level  language 
(say  AED)  implementations. 

Ease  of  maintenance  is  generally  improved  at  the  expense  of 
compiler  speed  and  size  by  means  of  such  techniques  as  top-down  design, 
modularity,  and  structured  programming.  Consequently,  the  methods 
used  to  improve  ease  of  maintenance  also  generally  reduces  the  cost  of 
development  for  the  compiler,  except  possibly  that  some  one-shot 
programming  training  costs  may  be  required  for  learning  the  techniques. 

Debugging  features  will  generally  add  to  development  costs. 
Generally  they  also  cost  something  in  compiler  performance.  However, 
it  appears  ihat  one  can  make  a quite  useful  generalization  concerning  the 
desirability  for  debugging  features  in  a compiler.  This  generalization 
will  be  presented  below  in  the  context  of  a general  comparison  of  one- 
pass  and  multi-pass  compilers. 


Contrasting  objectives  of  one-pass  and  multi-pass  compilers. 
Generally  a one-pass  compiler  is  designed  for  speed  as  a primary 
objective.  Multi-pass  compilers,  on  the  other  hand  are  designed  with 
a trade-off  of  the  various  factors  in  mind  to  achieve  an  appropriate 
balance  of  these  factors.  Consequently,  it  seems  desirable  to  have  two 
compilers,  if  budget  permits,  for  a given  language: 

• A one-pass  compiler  intended  primarily  for  debugging 
at  the  unit  testing  level. 

« A multi-pass  compiler  intended  for  system  integration 
and  the  compilation  of  final  production  run  object  code. 

This  compiler  should  include  instruments  to  facilitate 
the  development  of  static  and  dynamic  User  Profiles. 

Since  the  one-pass  compiler  is  intended  for  repeated  recompilations 
during  the  debugging  (unit  testing)  of  programs,  it  should  be  as  fast 
as  possible  and  should  have  a set  of  diagnostic  and  debugging  features 
which  are  suitable  for  minimizing  the  number  of  recompilations  and 
debugging  runs  required  to  successfully  unit  test  a module.  On  the 
o trier  nano,  u'16  Ouiy  opiirruZations  that  could  be  used  to  improve  object 
code  quality  are  those  of  the  peep-hole  object  code  post  processor 


32 


msmm 


variety  that  will  not  significantly  slow  down  the  compiler.  The  reason  for 
this  rather  extreme  position  favoring  compiler  speed  over  object  code 
quality  is  that  many  recompilations  are  likely  during  debugging,  and 
executions  will  generally  be  limited  to  partial  or  limited  trial  cases. 

The  multi-pass  compiler  must  balance  compiler  performance 
against  object  code  quality.  It  is  probably  desirable  to  be  able  to 
optionally  include  a variety  of  optimizing  passes  depending  on  whether  one 
is  in  the  system  integration  phase  or  the  final  compilation  of  production 
run  programs.  During  these  activities,  compiler  diagnostics  are  likely 
to  be  of  much  less  value  than  in  the  debugging  (unit-testing)  phase  using 
the  one-pass  compiler.  Furthermore,  it  is  desirable  to  instrument 
the  system  integration /production,  run  compiler  so  that  detailed  static 
and  dynamic  user  profiles  can  be  established.  These  profiles  and  instru- 
ments should  be  able  to  locate  bottlenecks  in  the  production  system  so 
that  the  system  can  be  fine  tuned,  and  bottleneck  programs  can  be  re- 
programmed or  recompiled  with  more  optimizing  options  so  as  to 
improve  overall  performance.  Compiler  aids  to  debugging  are  less 
important  in  these  stages  as  in  the  debugging  stage,  but  the  compiler 
should  still  create  some  support  for  symbolic  referencing /modifying  of 
programs  and  variables. 

The  remainder  of  the  review.  Section  2 following  will  present 
?.  brief  description  of  each  of  the  functional  elements  of  a compiler 
introduced  above.  Section  3 will  present  a characteristic  architecture 
for  a one-pass  compiler.  Section  4 will  present  a generalized  architecture 
for  multi-pass  compilers,  in  which  almost  every  functional  element  is 
a separate  pass  of  the  compiler.  This  generalized  architecture  will 
illustrate  how  various  architectural  choices  within  the  multi-pass  frame- 
work can  be  seen  as  appropriate  groupings  of  the  elements  or  phases  in 
to  fewer  phases. 
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Functional  Elements  of  Compilers 


In  this  section,  a brief  description  is  presented  for  each  of  the 
functional  elements  of  a compiler  that  were  introduced  in  Section  1. 


Lexical  analysis.  The  lexical  analyzer  scans  the  input  strings 
character  by  character  and  applies  lexical  formation  rules  for  tokens. 

If  the  input  source  language  program  is  interpreted  as  a one  long 
character  string,  then  the  output  of  the  lexical  processor  is  a sequence 
of  short  character  strings,  each  such  short  string  being  a lexeme.  In 
the  process  of  lexical  analysis,  comments  are  generally  removed,  and 
blanks  are  either  removed,  or  in  some  contexts,  converted  to  a standard 
punctuation  mark,  such  as  a comma.  As  a by  product  of  lexical  analysis, 
a lexical  code  is  usually  attached  to  the  lexeme  which  provides  some 
information  as  to  the  lexeme's  broad  category.  Examples  of  categories 
that  might  be  used  by  a lexical  analyzer  are  as  follows: 

• Punctuation  mark  (e.  g.  comma  (, ),  semi-colon  {;),  etc.). 

• Reserved  works  (e.  g. , GOTO,  CALL,  IF,  THEN,  etc.). 

• User  variable  names. 

• User  labels. 

• User  literals  (may  be  broken  down  by  data  type  of  literal). 

In  most  architectures,  the  lexical  analyzer  is  called  as  a subroutine 
by  the  parser  (one-pass  compilers)  or  by  the  declaration  processor 
(multi-pass  compilers).  When  called,  the  input  character  string  is 
scanned,  and  the  next  single  lexeme  formed  is  returned  as  output,  m 
the  multi-pass  architecture  presented  in  Section  4,  the  lexical  analyzer 
is  organized  as  a separate  phase  in  order  to  illustrate  the  many 
architectural  choices  available  for  grouping  the  functional  elements. 


Table  look-up.  The  table  look-up  function  accepts  as  input  a 
lexeme  which  is  the  output  of  the  lexical  analyzer.  Using  one  of  a variety 
of  mechanisms  (see  Chapter  4 ),it  is  determined  whether  or  not  an 
entry  exists  for  the  input  lexeme  in  a symbol  tablo.  If  so,  usually  the 
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location  of  the  entry  is  returned  as  output.  If  not,  a new  entry  is  made 
for  the  lexeme,  and,  usually,  the  location  of  the  new  entry  is  returned. 


In  a one-pass  compiler,  the  table  look-up  function  is  usually 
called  by  the  parser  immediately  after  a lexeme  is  returned  by  the 
lexical  analyzer.  In  a multi-pass  compiler,  the  table  look-up  function 
is  generally  called  by  the  declaration  processor,  which  is  a separate 
phase.  In  the  architecture  presented  in  Section  4,  the  table  look-up 
function  is  itself  organized  as  a separate  phase. 


Declaration  processing.  The  declaration  processor  accepts  as 
input  the  location  of  am  entry  in  a symbol  table,  output  by  the  table  look-up 
function,  and  an  appropriate  type  identifier  obtained  from  the  lexeme 
string  in  one  of  several  possible  ways.  The  declaration  processor  stores 
the  type  information  in  the  symbol  table  for  the  specified  entry;  it  produces 
no  output. 

In  a one-pass  compiler,  the  declaration  processor  is  called  by 

* the  parser.  In  this  case,  the  parsing  rules  include  productions  for 
declarations,  amd  when  the  parser  recognizes  that  a declaration  production 

* is  to  be  performed,  the  parser  calls  the  declaration  processor  to  perform 
the  work  associated  with  this  production. 

In  a multi-pass  compiler,  the  declaration  processor  is  usually  a 
separate,  pass.  In  this  case,  the  declaration  processor  usually  is 
organized  more-or-less  as  a special  parser  which  recognizes  just  those 
simple  syntactic  productions  related  to  declaration  keywords.  When  such 
a production  is  recognized,  then  the  appropriate  type  information  is 
stored  in  the  symbol  table  for  the  current  active  non -keyword  symbol 
table  entry. 

In  the  architecture  presented  in  Section  4,  the  declaration  processor 
I is  organized  as  a separate  phase  which  is  distinct  from  all  the  other 

I • functional  elements. 


Parsing,  The  parser's  function  <s  to  apply  the  syntax  rules  to 
the  source  program.  In  effect,  the  parser  may  be  thought  of  as  processing 
a sequence  of  symbols  (each  represented  by  a location  in  a symbol  table) 
stacking  the  symbols  on  a push-down  list  (until  a pattern  matcher  recognizes 
the  applicability  of  a syntactic  production),  invoking  an  appropriate  output 
function  for  the  recognized  production,  and  then  appropriately  modifying 
the  state  of  the  push-down  list.  (The  variety  of  alternative  parsing 
algorithms  is  discussed  in  Chapter  5. ) If  we  ignore  the  output  part  of 
the  parser's  activity,  then  the  parser  can  be  thought  of  as  placing  a pair 
of  syntactical  marks  (e.g.,  special  parentheses),  around  a syntactic 
phrase,  where  a syntactic  phrase  is  a sequence  of  elements,  each  of 
which  is  either  a symbol  or  a lower  level  syntactic  phrase.  The  particular 
form  of  output  used  depends  upon  how  the  parser  fits  into  the  overall 
compiler  architecture. 

In  a one-pass  compiler,  generally  the  parser  is  "boss".  The 
sequence  of  symbols  to  be  processed  are  "generated"  one  at  a time  by 
successive  calls  to  the  lexical  analyzer,  each  followed  by  a call  to  the 
table  look-up  function.  The  output  function  called  by  the  one-pass  parser 
"boss"  is  the  code  generator,  which  directly  produces  object  code  for 
the  recognized  syntactic  phrase. 

In  many  multi-pass  compilers  (e.g.  , the  AED  compiler),  the 
parser  is  a separate  phase  which  follows  the  declaration  processing 
phase.  The  parser  processes  the  linear  sequence  of  symbols  which 
constitutes  the  output  of  the  declaration  processing  phase.  Although 
the  code  generator  could  be  combined  with  the  parsing  phase,  in  most 
multi-pass  compilers  the  parser  invokes  a tree-builder  as  its  output 
processor. 

In  the  architecture  presented  in  Section  4,  the  parser  is  organized 
as  a separate  phase  in  which  the  output  generated  by  the  parser  is  simply 
the  linear  string  of  symbols,  together  with  the  pairs  of  special  syntactic 
parentheses.  Also  included  for  each  pair  of  special  syntactic  parentheses 
is  some  information  describing  the  global  state  of  the  push-down  list 
(beyond  the  top  portion  of  the  list  involved  in  the  matching  of  a syntactic 
production)  at  the  time  the  syntactic  phrase  is  recognized. 
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Tree  building.  The  vree  builder  is  used  in  multi-pass  compilers 
to  organize  the  parsed  phrases  recognized  by  the  parser  into  a hierarchical 
tree  structure  representation.  Whenever  the  parser  does  not  directly 
invoke  the  code  generator  as  its  output  process,  then  usually  a tree  builder 
is  invoked  so  that  the  information  representing  the  source  program  that 
survives  the  parsing  phase  is  in  tree  structure  form.  (Examples  include 
the  AED  and  J3B  compilers.  ) At  each  node  of  the  tree,  the  following  infor- 
mation is  generally  maintained: 

• The  location  of  one  symbol  or  keyword  in  a symbol/keyword 
table.  (Generally  bottom  nodes  correspond  to  user  symbols 
representing  operands,  and  non-bottom  nodes  correspond 

to  keywords  or  punctuations  corresponding  to  productions 
to  be  performed.  ) 

* State  information  representing  the  "global"  condition  of 
the  push-down  stack  at  the  time  the  syntactic  phrase  is 
recognized  by  the  parse1-. 

In  the  architecture  presented  in  Section  4,  the  tree  builder  is  a 
separate  phrase  distinct  from  the  parser. 


Set/nsed  analysis.  In  a multi-pass  compiler  the  set-used 
analyzer  develops  for  each  symbol  corresponding  to  a user  variable  a 
list  of  information  that  specifies  where  in  the  program  the  data  (contents 
of  storage)  associated  with  the  variable  is  set  (changed  or  stored)  and 
where  it  is  referenced.  In  addition,  it  may  be  convenient  to  "enerate 
a similar  list  for  the  setting  and  using  of  temporary  variables  associated 
with  intermediate  computational  expressions.  However,  if  machine- 
dependent  optimization  temporaries  is  desired,  then  information  as 
to  how  temporaries  are  used  and  set  can  be  generated  as  late  as  general 
object  code  post-processing. 

Set/used  analysis  can  be  performed  during  tree  building,  but  in 
the  architecture  presented  in  Section  4,  the  set/used  analyzer  is  a 
separate  phase. 
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.Set/used  analysis  is  used  in  order  to  perform  one  or  more  global 
machine  independent  optimizations.  These  optimizations  may  result  in 
further  modifications  of  the  set-used  information.  (See  Chapter  6. ) 

Flow  analysis.  The  flow  analyzer  is  used  in  multi-pass  compilers 
to  support  one  or  more  optimization  algorithms.  (See  Chapter  6 . ) 

The  flow  analyzer  processes  the  tree  structure  representation  of  the 
source  program  being  compiled  to  identify  those  nodes  corresponding 
to  straight  line  sequences  of  executable  code.  The  output  of  the  flow 
analyzer  may  either  be  a table  of  identified  groups  of  nodes,  or  suitable 
codes  entered  into  die  nodes  of  the  tree  structure. 

Architecturally,  the  flow  analyzer  cculd  be  attached  to  the  parsing 
phase,  cr  could  be  part  of  a global  machine  independent  optimization  phase 
which  follows  the  parsing  phase,  in  the  architecture  presented  in 
Section  4,  the  flow  analyzer  is  a separate  phase  that  is  invoked  one  or 
more  times  during  iterative  optimization  passes.  (See  Chapter  6.  ) 

Global  machine  independent  optimization.  In  some  multi-pass 
compilers,  this  function  takes  place  following  the  parsing  phase  and 
before  the  code  generation  phase.  The  purpose  of  this  function  is  to 
reorganize  the  tree  structure  representative  cf  the  source  programs 
so  as  to  produce  improved  performance  in  the  object  code  tc  be  generated. 
(See  Chapter  7 . ) Since  these  optimizations  may  result  in  altered 
set/used  patterns,  it  is  assumed  that  appropriate  changes  are  made  to 
the  set/used  information  as  part  of  the  function  c f optimization. 

In  the  ai  chitecture  presented  in  Section  4,  global  machine 
independent  optimization  is  represented  as  one  or  more  separate  phases 
that  may  be  iteratively  invoked  in  conjunction  with  iterative  invocations 
of  the  flow  analyzer. 

Storage  allocation.  In  one -pass  compilers , or  in  multi-pass 
compilers  without  set/ used  analysis  or  dead  variable  elimination  (during 
global  machine  independent  optimization),  storage  can  be  allocated  for 
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variables  immediately  after  declaration  processing.  Otherwise,  allocation 
of  storage  to  variables  is  done  in  conjunction  with,  or  following,  global 
machine  independent  optimization. 

Allocation  of  storage  for  temporaries  is  fairly  well'handled  by 
the  following  approach.  This  approach  operates  during  object  code 
processing  by  assigning  the  n(i,  j)-th  temporary  of  a given  data  type  (say, 
data  type  i)  to  the  n(i,  j)-th  sub-expression  (which  was  not  immediately 
used  as  an  operand  following  its  calculation)  of  that  data  type  within  the 
j-th  expression.  (Temporaries  for  common-3ub-expres3ions  are  allocated 

during  global  machine  independent  optimization. ) At  the  end  of  code 
generation,  space  for  = MAX  n(i,  j)  occurrences  of  data  type  i are 
allocated,  A somewhat  more  optimized  approach  would  reduce  the 
required  number  of  temporaries  during  general  object  code  post-processing 
by  taking  into  account  that  the  intermediate  calculated  result  is  preserved 
in  a register  until  needed,  and  therefore  does  not  have  to  be  stored  in  a 
temporary  location.  (See  discussion  for  register  allocation,  which  follows 
below.  ) 

In  the  architecture  presented  in  Section  4,  storage  allocation  for 
variables  is  a separate  phase,  and  storage  allocation  for  temporaries 
is  done  as  a separate  global  object  code  post-processing  phase. 


Register  allocation.  The  allocation  of  hardware  registers  (e.  g. , 
base  registers,  operand  registers,  index  registers)  to  variables  and 
indices  for  subscripted  variables  is  quite  complex  if  a highly  optimized 
approach  is  desired.  Probably. the  best  relatively  simple  approach  is 
for  a preliminary  assignment  of  registers  to  variables  to  be  made  as 
part  ol  machine  dependent  code  generation  using  a least  recently 
used  algorithm.  (Tie  previous  contents  is  allocated  a temporary 
storage  location  at  the  same  time,  and  the  old  contents  is  "tentatively" 
stored  in  the  temporary  at  this  time.  The  global  machine  dependent 
post-processor  will  eliminate  these  allocations  and  STORE  instructions 
from  /.he  object  code.  This  will  take  place  when  it  is  determined  that  the 
old  c intents  will  net  be  again  required  in  a computation  within  an  identified 
straight  line  sequence  of  executable  code.  ) 
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A least  recently  used  algorithm  can  be  incorporated  into  a cne- 
pass  architecture  (without  the  global  optimization  benefits,  of  course), 
as  well  as  in  multi-pass  compilers.  In  the  architecture  described  in 
Section  4,  it  is  assumed  that  the  above  described  approach  is  taken  for 
register  allocation,  although  the  architecture  includes  the  possibility 
of  using  alternative  selection  algorithms  other  than  the  least  recently 
used  algorithm. 


Machine  independent  code  generation.  The  separation  of  machine 

independent  and  machine  dependent  code  generation  functions  is  described 

in  some  detail  in  Chapter  7 . In  the  architecture  presented  in  Section  4,  , 

a table  driven  code  generator  approach  is  assumed,  and  the  machine  j 

independent  code  generator  is  organized  as  a separate  phase  which  j 

operates  in  a modified  fashion  from  the  procedure  described  in  Chapter  2 

for  table  driven  code  generation.  i 

I 

) 

Machine  dependent  code  generation.  As  indicated  above,  j 

i 

Chapter  7 presents  a detailed  discussion  of  the  separation  of  machine 
independent  and  machine  dependent  code  generation  functions.  In  the 
architecture  presented  in  Section  4,  the  machine  independent  code 

generator  is  also  organized  as  a separate  »e  which  operates  in  a j 

modified  fashion  from  the  procedure  described  in  Chapter  7 . ‘ 

I 

Peephole  object  code  post-processing..  This  activity  is  used  in 
one-pass  compilers  to  improve  the  quality  of  the  object  code  produced. 

A small  buffer  of  object  code  lines  examined  to  determine  if  simple 
machine  independent,  optimizations  can  be  performed.  The  most  common 
use  of  this  activity  is  to  eliminate  unnecessary  contiguous  LOAD  STORE 
pairs  of  instructions  which  result  from  two  consecutive  code  generation 
productions. 


General  object  code  post-processing.  This  function  serves  the 
purpose  of  performing  a number  of  global  machine  dependent  optimizations. 
As  discussed  in  Chapter  6 , this  type  of  optimization  is  probably  best 
handled  in  this  manner.  As  indicated  above,  register  allocation  and 
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storage  allocation  can  be  optimized  in  this  way.  In  the  architecture 
presented  in  Section  4,  a separate  general  object  code  posc-processor 
phase  is  included  as  the  last  phase  of  that  architecture. 


3. 


An  Architecture  for  a One-Pass  Compiler 


In  this  section  we  present  an  architecture  for  a one-pass  compiler 
which  is  more-ox -less  representive  of  how  one-pass  compilers  are 
organized  generally.  The  one-pass  compiler  architecture  is  illustrated 
in  Figure  1.  Certain  "boxes"  in  the  flow  chart  are  numbered  in  the 
upper  left  hand  corner.  These  "boxes"  correspond  to  basic  compiler 
functions  as  discussed  in  Section  2.  Note  that  four  error  conditions  are 
identified  in  the  flowchart  (El,  E2,  E3,  and  E4).  It  is  beyond  the 
intended  scope  of  this  discussion  to  elaborate  on  error -handling  in  the 
compiler. 

In  the  architecture  illustrated  in  Figure  1,  the  parsing  function 
is  "boss".  That  is,  the  main  routine  of  the  compiler  performs  the  parsing 
function  after  appropriate  initialization,  and  by  appropriate  invocations 
of  the  other  compiler  functions  as  subroutines.  Following  the  flow  in 
Figure  1,  we  see  that  after  initialization  and  opening  of  files  (and 
other  preliminary  I/O  functions),  the  lexical  analysis  function  (1)  is 
invoked  to  obtain  a character  string  corresponding  to  a lexeme.  This 
function  would  normally  use  system  I/O  functions  to  fill  input  stream 
buffers  as  they  were  scanned.  Any  error  detected  by  the  lexical  analyzer 
constitutes  a lexical  error  and  would  be  handled  by  some  appropriate 
mechanism  (not  shown)  following  the  node  El. 

The  character  string  lexeme  is  next  used  as  input  to  the  table 
look-up  function  (2).  If  no  entry  is  found,  then  the  table  look-up  function 
may  or  may  not  make  a new  entry  for  this  lexeme.  What  determines  this 
action  is  the  value  of  state  information  that  indicates  whether  or  not 
declaration  processing  (4)  is  complete.  The  state  variable  is  set  to 
indicate  that  declaration  processing  is  complete  in  conjunction  with 
the  storage  allocation  function  (5).  If  declaration  processing  is 
complete,  then  not  finding  an  entry  for  the  lexeme  constitutes  an  undefined 
symbol  error,  which  is  handled  by  appropriate  action  (not  shown)  follow- 
ing node  E2.  In  all  other  cases,  the  address  of  the  symbol  table  entry 
for  the  lexeme  is  returned  and  put  on  top  of  the  push-down  stack. 


At  this  point  a test  is  made  to  the  applicability  of  the  syntax  rules 
to  the  sequence  of  symbols  on  the  top  of  the  push  down  stack.  This  test 
constitutes  the  primary  parsing  function  (3)  activity.  One  of  three 
possible  results  can  occur  from  this  test  activity: 

• A match  is  found  indicating  the  applicability  of  a syntactic 
rule  that  permits  a production  to  be  applied  to  the  input  string 
of  symbols. 

• No  match  is  found. 

• A syntactic  error  is  detected. 

Syntactic  errors  are  handled  by  appropriate  functions  (now  shown) 
following  node  E3.  The  "no  match"  condition  implies  that  no  production 
is  applicable,  so  control  loops  back  to  lexical  analysis  to  obtain  another 
lexeme. 

A "match"  is  handled  as  follows.  First,  the  test  is  made 
to  determine  if  the  matching  production  indicates  that  the  end  of  the 
source  program  has  been  identified,  indicating  that  the  compiler  has 
completed  the  parsing  of  the  source  program.  If  this  is  the  case. 

Final  I/O  processing  takes  place  including  "flushing"  output  buffers  and 
closing  files,  followed  by  termination  of  the  compiler  activity. 

If  the  production  is  other  than  "end  of  program",  then  a test  is 
made  to  determine  if  the  production  is  a declaration  processing 
production  or  a code  generation  production.  Declaration  processing 
productions  are  handled  by  the  declaration  processing  function  (4). 

This  function  generally  stores  type  information  in  the  symbol  table  for 
a user  declared  variable.  The  first  time  a code  generation  production 
is  detected,  the  storage  allocation  function  (5)  is  invoked  to  allocate 
space  for  user  declared  variables.  (See  Section  2.  ) 

Wnereas  in  a multi-pass  compiler,  the  code  generation  production 
would  usually  result  in  some  activity  like  the  tree -builder  to  develop  an 
intermediate  representation  of  the  source  program,  in  a one-pass 
compiler,  the  production  instead  directly  invokes  appropriate  code 
generation  functions.  First,  the  machine  independent  code  generation 
function  is  invoked.  In  the  one  pass  compiler,  this  generally  consists 
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only  of  maintaining  state  information  (6)  to  be  used  during  machine 
dependent  code  generation  (7).  During  the  maintenance  of  state  infor- 
mation activity,  it  is  possible  that  the  compiler  might  detect  a fourth 
category  of  error  dealing  with  illegal  mismatching  of  data  types  or  values. 
These  errors  are  handled  by  appropriate  functions  (not  shown)  following 
node  E4. 

Since  the  reuult  of  the  machine  dependent  code  generator  is  a 
sequence  of  object  code  "lines"  added  to  an  output  buffer,  a peephole 
object  code  post-processor  (8)  examines  a few  lines  in  the  buffer  in 
order  to  make  minor  modifications  constituting  local  machine  independent 
optimizations.  (See  Section  2. ) 

Following  both  the  declaration  processing  function  (4)  and  peep- 
hold  object  code  post-processor  (8),  flow  loops  back  to  the  lexical 
analyzer  (1)  to  obtain  another  lexeme. 
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4 . An  Architecture  for  a Multi-Pass  Compiler 

In  this  section  we  present  an  architecture  for  a multi-pass  compiler 
in  which  almost  every  compiler  function  discussed  in  Section  2 is 
organized  as  a separate  phase.  The  purpose  of  this  architecture  is  to 
illustrate  two  points.  First,  the  degree  to  which  the  various  compiler 
functions  can  be  separated  so  as  to  minimize  core  requirements. 

Secondly,  the  extremes  of  separability  illustrated  demonstrates  un- 
mistakenly  that  very  numerous  alternatives  exist  for  combining  what 
are  presented  as  consecutive  sequences  of  compiler  phases  into  single 
phases  encompassing  more  than  one  compiler  function.  When  such 
combinations  are  made,  changes  naturally  occur  in  the  nature  of  the 
interface  data  used  between  phases  as  a means  of  inter -phase  communica- 
tion. 

Phase  1.  During  Phase  1,  initialization  is  performed,  files  are 
opened,  and  other  I/O  functions  of  a preliminary  characters  are  performed, 
substantially  the  same  as  in  the  one-pass  architecture.  (See  Section  3.  ) 
Then  the  1 leal  analyzer  is  iteratively  called  to  generate  a sequence  of 
lexemes,  also  in  a similar  manner  as  in  the  one-pass  compiler.  Here, 
however,  the  lexeme,  generated  is  directly  put  into  a buffered  output 
stream  for  processing  by  Phase  2. 

The  space  required  for  Phase  1 consists  of  that  needed  to  contain 
the  initialization,  I/O  support,  and  lexical  analysis  programs,  and 
data  structures  together  with  space  for  input  and  output  buffers. 

Phase  2.  I-htncticnally,  Phase  2 consists  entirely  of  the  table 
iook-up  activity.  In  addition,  I/O  support  functions  are  required. 

The  input  to  Phase  2 consists  of  the  sequence  of  lexemes,  suitably 
buffered,  as  output  by  Phase  1.  The  output  of  Phase  2 consists  of  a 
symbol  table  with  entries  for  each  user  declared  (or  defined)  lexeme, 
together  with  a suitably  buffered  output  stream  of  symbols,  each  being 
a location  of  the  symbol  in  the  symbol  table.  It  is  assumed  that  any 
permanent  data  used  for  the  table  look-up  functions,  such  as,  for 
example,  a partial  symbol  table  for  punctuation  and/or  key  words,  are 
included  with  the  tctal  symbol  table  indicated  above. 
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We  note  that  in  3ome  languages,  a suitable  use  of  key  words 
and/or  punctuation  would  permit  a separation  of  the  output  stream  into 
two  independent  streams:  one  for  declarations  and  one  for  executable 
statements. 

Phase  3.  Functionally,  Phase  3 consists  entirely  of  the  declaration 
processor.  In  addition,  I/O  support  functions  are  required.  The  input 
to  Phase  3 consists  of  the  symbol  table  and  the  sequence  of  symbol  table 
locations,  suitably  buffered,  which  constituted  the  output  of  Phase  2, 

(If  the  note  indicated  for  Phase  2 applies,  then  only  a part  of  the  entire 
output  stream  needs  to  be  processed  by  Phase  3.  ) 

Included  in  the  declaration  processor,  as  envisioned  in  the 
present  architecture,  is  a partial  parsing  function  for  just  those  syntactic 
rules  selected  to  declaration  processing.  Generally,  this  part  of  the 
syntax  should  constitute  only  a small  subset  of  the  total  syntax  of  the 
source  language.  As  declaration  productions  are  identified,  appropriate 
entries  are  made  in  the  symbol  table.  Also,  the  symbol  table  may  be 
structured  according  to  the  hierarchical  nesting  of  declaration  blocks, 
so  that  only  appropriate  portions  need  be  core  resident  during  parsing. 

The  space  required  for  Phase  3 consists  of  that  needed  to  contain 
the  declaration  processor  programs  and  data  structures  (including  the 
partial  parsing  functionality),  together  with  I/O  support  programs  ana 
data  structures,  and  additional  space  for  input  buffers  and  the  symbol 
table.  Note  that  no  buffers  are  required  for  an  output  stream  since 
Phase  3 does  not  generace  any. 

Phase  4.  Functionally,  Phase  4 consists  entirely  of  that  larger 
part  of  the  parser  dealing  with  the  syntax  of  executable  statements. 

In  addition,  I/O  support  functions  are  required.  The  input  to  Phase  3 
includes  the  symbol  table  as  modified  by  Phase  2,  suitably  organized 
hierarchically  so  that  only  appropriate  portions  need  be  core  resident 
while  parsing  within  nested  procedure  definition  and  block  boundaries. 

In  addition,  Phase  4 inputs  the  sequence  of  symbols  suitably  blocked, 
constituting  the  output  of  Phase  2.  If  the  note  indicated  for  Phase  2 


47 


applies,  then  only  a part  of  the  entire  output  stream  needs  to  be  pro- 
cessed by  Phase  4. 

In  the  present  architecture,  the  output  of  Phase  4 consists  of 
an  edited  ve:  sion  of  the  input  stream.  The  editing  consists  of  the 
insertion  of  pairs  cf  special  syntactic  parentheses  together  with 
appropriate  state  information,  as  described  in  Section  2. 

The  space  required  for  Phase  4 consists  of  that  needed  to  contain 
the  executable  statement  parser  programs  and  data  structures,  together 
with  I/O  support  prog~ams  and  data  structures,  and  additional  space 
for  the  symbol  table,  and  input  and  output  buffers.  Note  that  the 
separation  of  the  tree  building  function  fiom  the  parsing  phase  removes 
the  need  to  also  hold  the  tree  structure  representation  of  the  source 
language  program  '.n  core  concurrently  with  the  above  listed  items. 

Phase  5.  Functionally,  Phase  5 consists  entirely  of  the  tree 
builder  function.  (See  Section  2.  ) In  addition  I/O  support  functions 
are  required.  The  input  to  Phase  5 consists  of  the  output  stream, 
suitably  buffered  from  Phase  4.  Note  that  the  symbol  table  is  not  a 
required  input  for  the  tree  builder,  as  it  is  for  the  parsing  function. 
Furthermore,  the  tree  builder  is  a very  simple  function  as  compared 
with  the  parsing  function.  Input  support  functions  are  also  required. 

The  outpuc  of  the  tree  builder  is  the  tree  structured  representa- 
tion of  the  source  language  of  program  being  compiled.  State  infor- 
mation is  the  input  stream  (as  output  b>  the  parser)  is  placed  into  the 
appropriate  nodes  of  the  tree  structure.  Conceptually,  at  least,  it 
is  assumed  that  the  entire  tree  structure  remains  in  core  when  Phase  5 
completes  its  wo:k.  However,  in  practice,  the  tree  might  be  organized 
so  that  smaller  portions  can  be  sequentially  processed  by  later  phases 
provided  excessive  I/O  for  re-reading  and  re-writing  the  separate 
parts  can  be  avoided. 

The  space  required  for  Phase  :>  consists  of  that  needed  to  contain 
the  tree  builder  and  I/O  support  function  programs  and  data  structure, 
and  additional  space  for  I/O  buffers  and  the  tree  structure  output  of  the 
phase. 
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Phases  6,  ?,  and  8.  The  next  three  phases  cjnsists  of  the 
set/used  analyzer,  the  flow  analyzer,  and  the  global  machine  independent 
optimizer  recp“<~tively.  These  three  functions  are  optionally  used 
iteratively  to  perform  machine -independent  optimizations  as  described 
in  Chapter  6 . The  input  to  these  phases  is  the  tree  structure  output 
by  Phase  5 together  with  the  symbol  table  output  by  Phase  3.  The 
r«w "It  of  the  processing  performed  by  Phases  6,  7,  and  8 is  a restructuring 
of  tl  e tree  to  reflect  introduced  optimizations,  as  well  as  appropriate 
indications  in  the  s/mbol  table  of  unused  symbols  following  all  introduced 
optimizations. 

Each  of  the  three  Phases,  6,  7,  and  8 require  space  for  the 
symbol  table  and  the  tree  structure.  In  addition,  space  is  required  for 
the  respective  functional  programs  and  data  structures.  Note,  however, 
that  no  intermediate  file  interfacing  exists,  and  therefore  no  I/O  support 
functions  are  used  and  no  I/O  buffers  -ivq  required. 

Phase  9.  Functionally,  Phase  9 consists  entirely  of  the  part  of 
the  storage  allocation  function  dealing  with  user  declared  variables. 

(See  Section  2.  ) The  input  *-o  Phase  9 is  the  symbol  table.  The  output 
to  Phase  9 consists  of  entries  in  the  symbol  tab.  to  reflect  the  addresses 
within  blot. h;.  of  the  storage  allocated  to  various  variables,  and  an 
additional  table  (SYMDEF's  and  SYMREF's)  which  will  be  output  with 
the  object  code  in  a suitable  format  to  provide  linkage  for  external 
variables. 

The  space  required  for  Phase  9 consists  of  that  needed  to  contain 
the  storage  allocation  programs  and  data  structures  for  variable 
handling,  as  well  as  the  symbol  table  and  the  SYMDEF  and  SYMREF 
table  for  external  variables. 

Phase  10.  Functionally,  Phase  10  consists  of  a very  small  part 
of  the  machine  independent  code  generation  function  as  described  in 
Chapter  7 . This  small  function  is  described  in  Chapter  7 as  the 
recursive  Tree  Walker  (TW).  Support  output  functions  are  also  required. 
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Let  A denote  an  arbitrary  node  of  the  tree,  and  B and  C its  left 
and  right  descendents  respectively.  (Note  that  either  or  both  of  B and 
C may  be  NULL  nodes.  ) Phase  10  then  consists  of  a single  recursive 
call  to  TW  with  the  base  node  of  the  entire  tree  as  its  single  argument. 
TW  then  operates  as  follows: 

• Output  the  contents  of  node  A with  code  _1. 

• If  die  pointer  to  node  B is  not  NULL,  then  recursively 
call  TW  with  the  pointer  to  B as  argument. 

• Output  the  contents  of  node  A,  with  code  2 

• If  the  pointer  to  node  C is  not  NULL,  then  recursively 
call  TW  with  the  pointer  to  node  C as  argument. 

• Output  the  contents  of  node  A with  code  3. 

• Return  to  caller. 

it  is  clear  that  the  entire  effect  of  Phase  10  is  to  linearize  the 
information  contained  in  the  tree  in  exactly  the  same  sequence  as  would 
be  available  to  the  machine  independent  code  generator  as  described 
in  Chapter  7 . 

This  space  required  for  Phase  10  consists  of  that  needed  for 
the  TW  program  and  data  and  support  output  programs  and  data 
structures,  together  with  space  for  the  tree  and  output  buffers.  Note 
that  the  symbol  table  need  not  be  core  resident  during  Phase  10. 

Phase  11.  Functionally,  Phase  11  consists  of  the  major  part 
of  the  machine  independent  code  generator.  It  consists  of  a scanning 
program  which  linearly  scans  the  data  from  the  nodes  of  the  tree  as 
output  by  Phase  10.  For  each  node,  a call  is  made  to  an  appropriate 
node-type  related  program  which  consists  of  code  to  process  the  node 
for  each  of  the  tree  codes  that  can  accompany  the  node  information. 
Thus,  each  node-type  related  program  contains  the  functionality  of 
three  programs  as  described  for  the  code  generator  in  Chapter  7 . 

I/O  support  functions  are  also  required. 
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There  are  two  main  functions  performed  by  each  node-type  related 
program.  One  function  is  to  maintain  state  information  that  characterizes 
the  context  (derived  from  ancestor  nodes  from  the  tree)  that  may  effect 
the  interpretation  of  the  node  information.  The  other  function  is  to 
output  the  parameters  which  would  have  been  included  in  the  sequence 
of  calls  to  a table  driven  machine  dependent  code  generator  interpreter. 

In  Chapter  7 , the  machine  dependent  code  generator  calls  this 
interpreter,  but  in  the  present  architecture,  the  call  is  replaced  by 
putting  the  parameters  into  an  output  stream  to  be  processed  by  the 
machine  dependent  code  generator  in  a separate  phase. 

The  space  required  for  Phase  11  consists  of  that  needed  to 
contain  the  scanning  program,  the  various  node -type  related  programs, 

I/O  support  programs,  data  structures  for  these  programs,  and  space 
for  the  symbol  table  and  input  and  output  buffers.  Note  that  the  linearizing 
of  the  tree  by  Phase  10  removed  the  need  for  having  the  tree  concurrently 
core  resident  with  the  large  programs  of  Phase  11. 


Phase  12.  Functionally,  Phase  12  consists  of  am  input  stream 
scanning  function,  the  machine  dependent  code  generator,  a preliminary 
storage  allocator  for  temporary  variables,  and  a register  allocator. 
Support  I/O  functions  are  also  required.  The  input  to  Phase  12  is  the 
symbol  table  and  the  sequence  of  parameter  data,  suitably  buffered, 
which  was  the  output  of  Phase  11.  The  output  of  Phase  12  is  an  output 
stream  comprising  the  object  code  form  of  the  source  program  being 
compiled. 

The  input  stream  scanning  function  performs  some  initialization 
of  state  variables,  etc.,  and  then  scans  the  sequence  of  parameter  data 
combinations  in  order.  For  each  such  combination,  the  table  driven 
interpreter  (which  is  the  form  used  here  for  the  machine  dependent 
code  generator  ) is  called  with  the  parameter  list.  The  interpreter, 
as  part  of  its  functioning,  will  include  register  allocation  function  and 
a preliminary  temporary  variable  storage  allocation  function. 
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In  order  to  perform  these  functions,  each  register  will  be 
associated  with  an  identifier  for  its  contents  within  each  straight  line 
sequence  of  executable  code.  These  sequences  will  have  been  identified 
during  flow  analysis.  An  algorithm,  such  as  the  least  recently  usee 
algorithm,  will  be  used  to  reassign  a register  tc  new  contents  for  an 
intermediate  result  during  a calculation,  or  for  a compiler  assigned  •- 
temporary  resulting  from  common  expression  elimination  during  global 
machine  independent  optimization  (Phase  8).  As  each  reassignment 
is  made,  code  is  generated  to  store  the  previous  contents  (if  any  since 
the  beginning  of  a new  straight  line  sequence)  in  the  next  available 
temporary  location  of  the  appropriate  type  (e.g.  base  register /pointer; 
index  register/integer,  floating  point  register/real,  etc.  ).  When  the 
end  of  a straight  line  sequence  is  found,  the  bookkeeping  tables  are 
appropriately  updated  to  represent  the  fact  that  the  contents  of  registers 
are  no  longer  available.  This  may  also  result  in  code  being  generated 
to  store  the  present  contents  of  registers  in  temporary  storage  locations. 
The  final  temporary  storage  allocation  function  is  performed  in 
Phase  13. 


The  space  required  for  Phase  12  consists  of  that  needed  for  the 
table  driven  interpreter  and  its  data  structures  (including  those  for 
managing  register  allocation  and  storage  allocation),  the  input  stream 
scanning  program  and  I/O  support  functions  and  their  data  structures, 
and  additional  space  for  the  symbol  table  and  input  and  output  buffers. 


Phase  13.  This  phase  includes  a number  of  general  object  code 
post-processing  functions  used  for  global  machine  dependent  optimiza- 
tion. (See  Chapter  6 . ) In  particular.  Phase  13  includes  a function  to 
make  the  final  storage  allocations  for  temporary  variables.  I/O  support 
functions  are  also  required. 

The  input  to  Phase  13  is  the  object  code  output  by  Phase  12. 

The  output  of  Phase  13  (including  all  such  post  processing  activities)  is 
an  edited  form  of  the  object  code. 
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The  final  storage  allocation  for  temporary  variables  works  as 
follows.  The  object  code  is  scanned  to  determine  those  occasions  where 
the  stored  value  in  a temporary  is  not  subsequently  used.  In  such  cases, 
the  STORE  instruction  can  be  detected,  and  the  storage  for  the  temporary 
may  be  deleted  if  all  such  uses  are  eliminated. 

The  space  required  for  Phase  13  consists  of  that  required  for 
the  particular  post  processor  functions  and  I/O  support  functions  and 
their  respective  data  structures  (including  bookkeeping  tables  such  as, 
for  example,  for  the  storage  allocation  functions  described  above), 
together  with  space  for  input  and  output  buffers. 
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1 . Overview 

This  chapter  reviews  the  set  of  compiling  algorithms  which  are  classed 
as  table  look-up  algorithms.  In  this  class  are  included  all  those  algorithms 
for  organizing  information  into  a number  of  different  structures  and  access- 
ing any  specific  entry  only  through  the  use  of  a single  identifying  attribute. 
Many  such  algorithms  have  been  developed  for  use  in  assemblers,  compilers, 
and  filing  systems,  and  many  have  been  thoroughly  modeled  and  analyzed 
mathematically.  The  structures  used  by  these  algorithms  are  not  necessari- 
ly tables,  but  also  include  tree  structures  as  well.  In  a.ddition,  the  various 
structures  may  have  many  different  internal  organizations,  and,  consequently, 
they  have  definite  ranges  of  performance  characteristics  which  are  dependent 
on  the  manner  in  which  that  information  is  accessed,  altered,  and  processed, 
as  well  as  on  the  attributes  of  the  information  which  is  3tored  into  them. 

The  first  sections  of  this  chapter  discuss  the  various  computational 
struchires  which  support  table  look-up  operations,  and  these  are  di  assed 
independent  of  any  specific  application.  The  remaining  sections  explore  the 
application  environment  for  table  look-up  algorithms  within  the  context  of 
compilers.  The  concluding  section  summarizes  and  highlights  some  of  the 
more  interesting  tiade-off  and  performance  aspects  for  the  algorithms  and 
the  applications  which  are  discussed.  As  is  indicated  in  this  last  section, 
Section  5,  the  greater  part  of  the  information  and  data  presented  here  is 
drawn  from  the  Art  of  Computer  Programming,  Vol.  Ill,  by  D.E,  Knuth, 
and  this  survey  is  augmented  with  results  from  a number  of  reports  and 
papers  which  have  appeared  since  this  book  was  published. 


Categories  of  Table  Look-up  Algorithms 


Table  look-up  algorithms  fall  primarily  into  four  broad  categories 
determined  by  the  data  access  methods  and  storage  organizations  they 
employ. 


54 


t*-'.  ,,u  ,i.  ju.-ni..  n ujjipp^wit  l !..  w.  ^Tmrnmrnmmmmmsmmsmwm 


i 


f 


1.  Sequential  list  algorithms  are  the  simplest  with 
information  taking  on  uncomplicated  tabular  or  liBt 
forms,  The  searching  techniques  used  are  strictly 
serial,  possibly  taking  advantage  of  orderings  cn  the 
table  to  gain  advantages  in  performance. 

2.  Binary  table  algorithms  operate  on  ordered  tables 
and  have  average  and  worst  case  retrieval  properties 
which  make  them  attractive  for  certain  applications. 

3.  Tree  organizations  allow  great  flexibility  in  providing 
rapid  updating,  and  well  defined  worst  case  performance. 
Most  tree  structures  are  either  the  simple  binary  form, 
or  the  more  complicated  multi-way  forms. 

4.  Hashing  and  algorithms  built  around  hashing  as  a basic 
function  have  emerged  as  th^  most  useful  class  of  table 
look-up  algorithms  to  date.  They  are  particularly 
interesting  in  the  mathematical  problems  involved  in 
their  analysis,  and  considerable  work  has  been  done 

in  this  area. 

Each  of  these  broad  classes  provide  specific  opportunities  for  the  system 
designer  to  adapt  a particular  algorithm  to  his  needs  and,  in  some  cases, 
to  even  mix  the  strategies  of  two  or  more  such  algorithms  to  synthesize 
a system  with  more  desirable  performance  characteristics.  Discussed 
in  the  sections  which  immediately  follow  are  the  basic  data  structures, 
and  the  operations  performed  on  them,  which  characterize  the  above  four 
categories. 


Sequential  Algorithms  The  simplest  algorithms  involve  straightforward  se-  1 
quential  search  of  «*.  tabular  data  structure.  Each  element  of  the  table  is 
examined  in  sequence  starting  with  the  first,  until  either  the  desired  element 
is  found  or  the  end  of  the  table  is  reached,  indicating  that  the  element  is 
absent.  The  best  case  performance  results  when  the  desired  element  appears 
first  in  the  table,  and  the  search  process  terminates  immediately.  The  worst 
case  performance  results  when  the  desired  element  is  nonexistent  or  appears 
last  ii.  the  table,  in  which  case  all  the  elements  of  the  table  must  be  examined 
in  turn.  Given  a table  of  N elements,  each  accessed  with  the  same  frequency, 
the  average  number  of  probes  A,  required  for  retrieval  of  an  element  is 
A = N/2.  That  is,  the  average  number  of  probes  grows  linearly  with  the 
length  of  the  table. 

Some  improvements  in  performance  can  be  gained  whenever  there 
are  differences  in  the  frequency  of  retrieval  requests  for  the  elements.  This 
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is  achieved  by  ordering  the  elements  in  the  table  so  that  their  positions 
correspond  to  their  frequency  of  access.  More  frequently  accessed  informa- 
tion appears  earlier  in  the  table  than  less  frequently  accessed  information, 
yielding  a reduction  in  the  average  number  of  probes,  with  the  reduction 
dependent  on  the  frequency  distribution  of  the  elements.  If  the  elements 
of  a table  are  ordered  on  frequency,  and  the  frequencies  form,  for  example, 
the  sequence  fj  = 1/2,  ....  fj  = 1/(2^),  then  the  average  number 

of  probes  can  be  shown  to  be  a = 2-1/2^"^. 

The  deletion  of  a table  element  or  a contiguous  block  of  table  elements 
can  be  achieved  by  marking  them  as  non-existent;  however,  since  these 
elements  must  be  accessed  examined  during  the  retrieval  of  any  elements 
which  follow  them  in  the  table,  they  contribute  to  the  cost  of  retrieving 
those  elements.  This  cost  may  be  reduced  through  a compaction  of  the 
table  to  reclaim  the  space  taken  up  by  elements  marked  for  deletion  but 
not  physically  removed.  The  cost  of  performing  the  compaction  is  simply 
the  cost  of  moving  the  elements  of  the  table  into  the  vacated  positions,  and 
the  decision  to  compact  can  be  made  whenever  this  cost  is  exceeded  by  the 
average  cost  of  retrieving.  For  tables  which  are  ordered  on  frequency  of 
access,  deletions  and  compactions  preserve  this  ordering. 

Insertions  for  tables  without  frequency  ordering  are  achieved  by 
adding  the  element  to  be  inserted  to  the  end  of  the  table.  Tables  with  such 
ordering  require  that  the  new  element  be  placed  within  the  table  at  the 
appropriate  position,  and  this  generally  requires  that  all  elements  following 
it  in  the  order  be  physically  shifted  down  one  position  to  make  room.  The 
cost  of  making  an  insertion  into  a frequency  ordered  table  consists  of 
the  number  of  accesses  required  to  find  the  appropriate  position  and  the 
data  movement  required  to  displace  the  following  entries  down  one 
position. 


A dynamic  frequency  ordering  can  be  achieved  by  treating  the  table 
as  a least  recently  used  stack.  That  is,  each  element  is  moved  to  the 
’top1  of  the  table  whenever  it  is  accessed  and  the  topmost  elements  are 


pushed  uGwii,  thud  allowing  the  table  to  uy iiaHiiCally  adjuot  tO  whatcV 6 T 


access  pattern  exists  at  a particular  time.  More  frequently  accessed 
elements  will  tend  tc  move  to  the  top  of  the  table,  while  elements  which 


tend  to  be  less  frequently  used  will  move  to  the  bottom  of  the  table.  Dele- 
tions and  insertions  in  this  scheme  can  be  handled  as  in  the  unordered  table, 
with  the  usage  pattern  of  the  newly  added  or  remaining  elements  being  deter- 
mined by  the  pattern  of  accesses  to  them. 


Binary  search  algorithms.  Binary  search  algorithms  operate  on  tables 
which  have  some  content  dependent  ordering  defined  for  them.  This  order- 
ing is  usually  achieved  by  treating  each  element's  identifying  field  as  a 
numeric  or  alphanumeric  field,  and  then  sorting  the  table  using  this  identifier 
as  a primary  key.  For  a table  of  length  N,  the  search  begins  by  first  com- 
paring the  key  of  the  table  entry  whose  position  is  closest  to  N/2  with  the 
key  of  the  desired  element.  If  the  two  keys  agree,  then  the  search  is  suc- 
cessful. and  the  desired  element  has  been  found.  If  the  search  key  is  greater 
than  the  table  entry  key,  the  desired  element  must  be  found  in  the  half  of  the 
table  having  all  elements  with  keys  greater  than  that  of  the  table  entry.  The 
converse  applies  if  the  search  key  is  less  than  the  table  entry  key.  In  either 
case,  half  of  the  table  has  been  excluded  from  the  search  on  the  basis  of  this 
one  comparison.  The  search  then  proceeds,  treating  the  proper  half  of  the 
table  in  the  same  manner  as  above.  The  search  terminates  either  on  locating 
the  desired  element,  or  on  finally  halving  the  table  to  just  one  entry.  The 
maximal  length  search  requires  log^J  comparisons  and  the  average  number 
of  comparisons  is  A = log2(N-l). 


Insertions  and  deletions  are  achieved  in  the  same  manner  as  for 
frequency  ordered  sequentially  searched  tables.  That  is,  an  element 
inserted  in  the  binary  search  table  must  be  positioned  so  as  to  preserve 
the  ordering  defined  by  the  key  values.  Elements  following  the  one  to  be 
inserted  must  be  moved  down  in  the  table  to  provide  room.  Deletions  can 
be  accomplished  by  marking  elements  as  non-existent,  and  the  table  com- 
pacted when  the  cost  of  handling  those  deletions  rises  above  some  thresh- 
hold.  A number  of  properties  of  the  binary  search  algorithm  make  it 
attractive  for  use  in  table  look-up  applications.  Among  these  there  is 
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which  is  very  close  to  the  average  performance  of  the  algorithm.  In 
addition,  the  ordering  defined  on  the  table  is  an  intuitive  one,  and  the 
table  can  be  brought  into  initial  order  with  the  use  of  standard  sort 


57 


algorithms,  without  additional  data  on  access  patterns  as  required  by 
frequencey  ordered  tables. 

Tree  searching  algorithms.  These  algorithms  operate  on  tree  like  data 
structures  where  each  node  in  the  tree  represents  a data  element.  Such 
algorithms  have  starch  patterns  that  begin  with  the  top,  or  root  node  of  the 
tree  and  successively  isolate  subtrees  which  are  searched  until  the  desired 
element  is  located  or  found  to  be  absent.  The  most  common  tree  form 
used  is  the  binary  tree  in  which  each  node  cam  have  at  most  two  successor 
nodes  as  indicated  in  Figure  2. 


Figure  2 - Typical  Node  Relationships  for  a Tree  Structured  Search  Table 


Some  tree  forms  allow  a parent  node  to  have  many  successors;  others 
require  that  the  data  elements  stored  in  the  tree  be  situated  at  the  lowest 
level,  with  the  nodes  having  values  which  guide  the  search  to  the  proper 
element  at  this  level.  In  the  interest  of  brevity  we  will  discuss  only  the 
binary  tree  and  some  variations  on  this  structure  which  improve  perform- 
ance of  the  algorithm  for  specific  classes  of  use. 


In  the  binary  tree  search,  the  key  of  the  desired  element  is  compared 
with  the  key  of  the  root  node.  If  the  key  is  equal  to  that  of  the  root  node, 
the  search  is  successfully  terminated.  If  the  key  is  greater  than  the  key 
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root  node.  The  converse  of  this  applies  if  the  key  is  less  than  that  of  the 
root  node  element.  Eventually,  the  proper  node  is  found,  or  the  search 
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terminates  at  a node  which  has  no  successor  pointer  for  the  result  of  the 
comparison  of  the  desired  key  with  the  key  at  that  node.  An  example  tree 
is  shown  in  Figure  3 employing  a set  of  keys  entered  in  the  order  D,  C, 

A,  B,  F.  E.  G. 


The  resulting  tree  has  the  property  of  being  partially  ordered.  That  is, 
all  nodes  subordinate  to  right  successor  of  a given  node  are  all  greater  than 
that  node,  and  conversely  all  nodes  subordinate  to  the  left  successor  of  a 
given  node  are  all  less  than  that  node.  Thus  in  searching  such  a tree  the 
pattern  of  accesses  to  nodes  proceeds  from  level  to  level,  isolating  at  each 

level  successively  smaller  subtrees  for  examination.  While  this  search 
pattern  resembles  closely  that  of  a binary  table  search,  the  average  and 
maximum  number  of  comparisons  required  span  a rather  wide  performance 
range.  For  a tree  which  is  well  balanced,  the  search  length  is  proportional 
to  log  N,  and  for  unbalanced  trees  the  search  length  is  proportional  to  N. 
(This  worst  case  performance  results  from  entering  a set  of  elements  in 
inverted  order,  with  the  greatest  key  first,  and  the  least  key  last.  ) 

Deletions  in  binary  trees  require  some  care  in  preserving  whatever 
balance  exists  in  the  tree.  Proper  deletion  strategies  prevent  any  one 
path  in  the  tree  from  growing  much  shorter  than  any  other  path.  Insertions 
require  that  the  tree  be  searched  for  an  available  position  in  much  the 
same  manner  as  a retrieval  is  performed;  the  new  node  becomes  the  left 
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or  right  successor  of  the  appropriate  node.  Various  specialized  algorithms 
(such  as  the  AVL,  balanced  tree  scheme)  have  been  developed  to  create  and 
maintain  a pseudo-random  distribution  of  key  values  at  the  nodes,  thereby 
bounding  the  average  and  worst  case  performance. 

The  binary  searched  tree  is  attractive  for  several  of  its  retrieval 
and  update  characteristics.  Among  these  are  the  similarity  of  its  perform- 
ance to  thac  of  the  binary  searched  table.  The  tree  form  also  facilitates 
the  insertion  and  deletion  of  data  elements  without  involved  data  movement 
or  displacement  of  existing  elements  within  the  tree.  To  implement  this 
algorithm,  some  sort  of  dynamic  storage  algorithm  is  necessary,  and  in 
determining  cost  of  updating,  the  work  required  for  managing  the  storage 
pool  must  be  taken  into  account. 

Hashing  algorithms.  Hashing  algorithms  have  grown  to  be  the  method  of 
choice  in  many  of  the  compiling  systems  currently  used.  These  algorithms 
must  operate  on  a fixed  sized  table,  say  of  length  N,  and  treat  each  of  the 
available  locations  as  addressable  by  an  integer  between  0 and  N-l.  To 
locate  the  address  of  the  position  in  the  table  where  a given  element  is  to  be 
stored,  tie  key  associated  with  that  element  is  mapped  via  some  numerical 
function  onto  the  integers  0,  1,  2,  . . . , N-l.  The  value  of  the  function  for 
each  key  is  taken  to  be  the  address  of  the  appropriate  table  position.  If  the 
function  which  is  chosen  to  perform  this  mapping  is  fairly  well  behaved,  most 
of  these  data  elements  would  map  to  unique  addresses,  and  a few  would  map 
to  the  same  address.  To  resolve  the  conflict  at  those  addresses  which 
are  assigned  more  than  one  element  under  the  mapping,  a secondary  function 
must  be  applied  to  determine  which  elements  to  assign  to  those  table 
positions  which  remain  unoccupied.  As  with  the  actual  mapping  function, 
the  conflict  resolution  may  be  performed  in  many  different  ways.  A 
considerable  amount  of  work  has  been  performed  on  the  behavior  of  both 
hashing  functions  and  conflict  resolution  or  overflow  functions.  Under  the 
assumption  of  a fairly  good  hashing  function,  and  assuming  that  the  table 
is  to  be  filled  with  K elements,  where  K < N,  the  average  number  of 
comparisons  for  a linear  search  overflow  method  is  found  to  be 
A = 1/2  (1  + 1/(1  - a)),  where  a = K/N  represents  the  fraction  of  total 
positions  that  are  occupied.  Comparable  results  are  obtained  for  other 
conflict  resolution  methods. 
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Insertions  and  deletions  are  constrained  to  preserve  the  sire  of  the 
table,  since  this  number  is  a parameter  of  the  mapping  functions  and  must 
remain  unchanged  if  all  the  other  elements  are  to  remain  addressable. 

Once,  under  successive  insertions,  the  table  becomes  full,  a new  one  must 
be  created,  in  order  to  increase  the  size  of  the  table.  If  under  deletions, 
the  ratio  a grov/s  very  small,  considerable  effort  is  required  in  order  to 
reclaim  the  unused  space.  Despite  these  minor  disadvantages,  the  average 
cost  of  retrieving  information  from  hash  addressed  tables  makes  them 
quite  attractive  in  terms  of  their  use  in  compilers.  Empirical  studies  have 
shown  that  average  retrieval  costs  for  reasonable  sized  tables  can  be  made 
to  approach  very  close  to  one  comparison  at  the  expense  of  allowing  unused 
storage  in  the  table  to  keep  the  loading  factor  at  somewhat  less  than  one. 
Additional  reductions  in  average  retrieval  costs  can  be  gained  by  entering 
elements  into  the  table  in  the  order  of  decreasing  frequency  of  usage. 
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3.  Compiling  Applications 

All  of  the  table  look-up  algorithms  described  in  Section  2 have  been  em- 
ployed in  compiling  systems  to  implement  a wide  variety  of  functions  which 
require  table  look-up  activity  for  their  operation.  The  most  familiar 
and  well  known  of  these  applications  are  symbol  table  management  and 
pattern  recognition.  Pattern  recognition  is  used  in  compilers  to  identify  par- 
ticular constructions  which  can  be  reduced  to  simpler  ones,  or  for  which 
optimized  code  generation  sequences  can  be  formed.  Such  uses  attempt  to 
improve  the  object  code  produced  by  a compiler  by  reducing  the  space  it 
occupies  and/or  by  the  run-time  required  to  execute  it.  Some  discussion 
of  the  usag  > of  table  look-up  algorithms  for  optimization  can  be  found  in 
Chapter  6. 

The  most  wide-spread  use  of  table-look-up  methods,  however,  has 
been  in  the  area  of  symbol  table  management  for  compiling  systems,  and  the 
following  discussion  presents  some  of  the  specific  applications  and  various 
factors  which  affect  performance  of  the  algorithms  in  those  applications. 

Symbol  tables  are  used  to  recognize  and  manage  information  about 
several  classes  of  symbols  which  are  encountered  in  source  language 
programs.  Some  tables  are  used  to  identify  special  key  words  or  tokens 
which  have  preassigned  meanings;  others  are  used  to  store  user  defined 
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symbols  and  their  attributes;  specialized  tables  are  used  to  store  whatever 
literals  appear  in  a source  program.  The  lexical  analysis  and  declarations 
processing  phases  of  compilation  perform  the  translation  of  source  program 
character  strings  first  to  language  tokens,  and  then  to  symbol  table 
locations.  These  can  be  used  by  the  following  parsing  and  code  generation 
phases  in  retrieving  whatever  symbol  attribute  information  they  require.  Of 
the  three  classes  of  symbols,  key  words,  user  symbols,  and  literals,  key 
words  present  the  least  difficulty  in  symbol  table  management.  Key  words, 
such  as  'IF',  'THEN',  'FOR',  can  all  be  organized  into  a single  convenient 
table,  and  each  name  encountered  in  the  program  can  be  easily  compared 
against  entries  in  this  table  to  determine  if  it  is  a key  word.  If  key  words 
are  maintained  in  a separate  area,  they  can  be  ordered  on  frequency,  for 
more  efficient  searching.  Alternatively,  all  the  key  words  can  be  stored 
along  with  user  defined  symbols,  generally  without  disturbing  the  structure 
of  the  table,  allowing  the  same  access  routines  to  be  used  for  both  classes 
of  vmbols.  Since  their  attributes  are  fixed,  and  predefined,  such  symbols 
present  no  insertion,  or  deletion  problems,  and  are  subject  only  to  retrieval. 
Because  key  words  have  fixed  attributes  they  are  sometimes  referred  to  as 
permanent  symbols. 

User  symbols  require  both  insertion  and  retrieval  operations,  and 
in  some  languages  with  block  structure,  they  also  require  deletion  operations 
or  their  equivalents.  Insertions  of  user  symbols  are  performed  at  their 
point  of  definition.  In  many  languages  user  symbols  are  defined  by  their 
first  usage,  v.  1th  their  attributes  being  determined  by  the  context  of  that 
usage,  or  by  implicit  spelling  rules;  this  is  true  for  example  of  FORTRAN. 
Other  languages  require  explicit  declarations  of  all  user  symbols  before 
their  usage,  and  certain  of  these  languages  restrict  such  declarations  to 
all  appear  together  in  a declaration  portion  of  the  source  program.  How- 
ever, since  empirical  studies  have  shown  that  user  symbols,  similar  to 
key  word  symbols,  are  heavily  biased  toward  retrieval,  insertion  operations 
represent  a one  time  cost  which  can  be  significantly  less  than  the  total  cost 
of  retrieval  over  a compilation. 

Literals  such  as  '1',  '3.  145V1,  '-10'  etc.,  are  almost  universally 
defined  by  their  usage,  and  are  usually  maintained  in  a table  organized 
pool.  A compiler  usually  allocates  a literal  to  a created  'constant'  \ariable, 
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and  will  search  this  pool  to  avoid  duplicate  created  constants.  This  form 
of  retrieval  can  be  facilitated  by  transforming  the  literal  to  a bit  string  in 
a constant  form,  and  then  using  this  string  as  an  identifier  for  the  table 
look-up  operation.  Thus  '1.  E+01'  and  '10.  O'  would  both  have  the  same  bit 
string  representation,  and  would  identify  the  same  literal. 

i.  Language  and  Program  Structure 

The  structure  of  a source  language,  and  the  form  of  source  programs 
written  in  it,  can  have  some  effect  on  both  the  choice  and  performance  of 
a particular  table  look-up  algorithm  for  symbol  table  management,  "his 
is  particularly  true  of  languages  which  permit  block  structure  eithe.  with 
or  without  the  qualification  of  user  symbols  wiJun  a block  by  the  block 
name.  The  effect  of  block  organization  is  to  cause  all  symbols  defined 
within  a block  to  refer  only  to  storage  associated  with  that  block,  even 
though  a containing  or  possibly  separate  block  may  also  define  symbols 
with  the  same  spelling.  The  effect  of  qualification  is  to  permit  within  any 
given  block,  explicit  reference  to  symbols  of  another  block,  by  simply 
qualifying  the  symbol  name  with  the  name  of  the  external  block.  Both  o. 
these  features  require  modifications  to  the  simplified  table  look-up 

algorithms  which  permit  the  compiling  system  to  distinguish  reference 
to  user  symbols  on  the  basis  of  block  context.  The  general  appearance 
of  such  symbol  table  management  is  to  create  a separate  symbol  table  for 
a block  when  it  is  entered,  use  this  to  satisfy  retrievals  of  symbols  local 
to  the  block,  and  then  erase  this  symbol  table  when  the  block  is  passed. 
Symbols  which  were  defined  previous  to  that  block  can  then  be  retrieved 
in  a logically  consistent  manner. 

One  such  scheme,  employed  by  the  AED  compiler,  uses  a Master 
Spelling  Table  to  hold  all  the  unique  spellings  of  symbols  encountered  in  all 
the  blocks  of  a program,  and  separate  sub-tables  (Block  Attribute  Tables), 
each  subordinate  to  a block,  to  hold  all  the  attributes  of  the  associated 
symbols.  Access  to  the  Master  Symbol  Table  is  via  hashing  of  the  symbol 
spelling  name.  Associated  with  each  name  in  the  table  is  a pointer  to  its 
currently  active  attribute  entry.  For  instance  consider  the  following  program 
schema. 
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BLOCK  B1  ; 

DEFINE  A,  B; 

BLOCK  B2; 

DEFINE  A,  C; 
END  B2; 

END  Bl; 


At  the  point  when  the  second  'BLOCK1  definition  is  encountered  the  Master 
Spelling  Table  and  Block  Atti ibutes  Table  resembles  the  configuration  shown 
in  Figures  4 and  5. 


A 

© 

B 

© 

Figure  4 - Illustrative  Master 
Spelling  Table  - 
Stage  1 


Figure  5 - Illustrative  Block 
Attributes  Table  - 
Stage  1 


Now  when  the  new  definition  of  A is  encountered,  the  Master  Spelling  Table 
entry  for  'A'  is  altered  to  associate  that  spelling  with  the  attribute  entry 
subordinate  to  block  B2,  and  a copy  of  the  old  association  is  placed  in  that 
entry. 


The  Master  Spelling  Table  and  Block  Attribute  Tables  now  resemble 
the  configuration  shown  in  Figures  6 and  7. 


Figure  6 - Illustrative 

Master  Spelling 
Table  - Stage  2 


Block  Bl. 


Block  B2. 


Figure  7 - Illustrative  Block  Attributes  Table 
Stage  2 


When  block  B2  is  exited,  the  copy  is  recovered,  and  replaced  in  the  Master 
Spelling  Table,  restoring  A's  old  association  block  Bl. 

Block  qualification  can  also  be  handled  transparently  using  hashing 
by  appending  to  each  symbol  an  identifier  for  the  block  which  defines  the 
symbol,  thus  achieving  uniqueness,  and  then  using  this  unique  spelling  as 
an  argument  to  the  hashing  function. 

Binary  tree  organizations  are  fairly  adaptable  to  such  wholesale 
deletions  and  insertions,  provided  those  operations  preserve  random  dis- 
tribution of  the  symbols  throughout  the  tree,  and  avoid  serious  degradation 
in  performance. 

5.  Summary  and  Conclusions 

The  above  material  has  summarized  salient  features  of  table  look-up 
technology,  and  the  compiling  environments  where  table  look-up  algorithms 
are  applied.  The  specific  performance  behavior  of  all  these  methods, 
or  the  impact  of  the  compiling  environment  on  this  behavior  has  not  been 
considered.  As  indicated  in  the  introduction,  much  of  the  relevant  analysis 
is  contained  in  The  Art  of  Computer  Programming.  V01.  3,  by  D.  E.  Knuth, 
and  the  reader  is  directed  there  for  specific  details,  proofs,  and  the  like. 
Additional  references  are  founa  at  the  end  of  this  report. 

The  basic  conclusions  can  be  summarized  briefly  in  the  following 
statements,  which  have  to  do  with  trade-off  and  performance  aspects  of 
the  methods  described  above. 
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• Each  algorithm  has  performance  characteristics 
which  favor  its  use  in  particular  applications.  The 
following  is  a brief  summary  of  the  areas  of  per- 
formance trade-offs: 

• Very  short  fixed  lists  can  be  organized  for 
sequential  search  table  management  with 
reasonable  efficiency  if  the  data  elements 
are  ordered  in  frequency  of  use.  Moderately 
small  variable  bits  might  be  better  treated 
with  sequential  methods  than  with  binary 
search  methods,  although  some  hashing  methods 
will  give  improved  performance  unless  block 
oriented  processing  is  required. 

• Moderately  large  lists  are  amenable  to  binary 
tree  representations,  although  variability  in  the 
tree  introduced  by  block  inserts  and  deletes  will 
in  general  disturb  the  average  performance 
characteristics  of  the  search  straregy. 

• Very  large  lists,  or  no  block  oriented  processing 
for  any  but  the  smallest  lists,  are  best  treats  \ 
using  hashing  methods.  Proper  choice  of  a hashing 
function,  collision  resolution  method,  and  loading 
factor  (either  through  analysis  or  empirical  study) 
can  achieve  very  attractive  average  performance 
characteristics.  BIock  oriented  processing  requires 
some  care  in  the  implementation  of  search  strategies 
to  avoid  introducing  excessively  large  overhead  costs. 
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CHAPTER  5 
PARSING  ALGORITHMS 


1 . Overview 

This  chapter  presents  the  results  of  a review  of  parsing  algorithms 
conducted  during  the  study.  The  general  conclusions  reached  from  our 
study  of  parsing  algorithms  is  as  follows: 

• For  most  parsing  techniques  in  common  use,  differences  in 
implementation  overshadow  differences  in  technique  in 
impact  on  performance. 

• For  one  technique  category  ("general  techniques"),  which 
is  not  commonly  used  in  compilers,  the  performance  ex- 
pected would  generally  be  poor  due  to  the  generality  of  the 
technique.  This  expected  poor  performance  is  probably  the 
reason  the  technique  is  not  commonly  used  in  compilers. 

• The  reasons  a particular  technique  is  selected  for  use  in 

a compiler  are  generally  distinctly  independent  of  performance 
considerations. 

• Aside  from  performance  considerations,  it  is  possible  to 
make  some  general  statements  about  various  advantages  or 
disadvantages  one  parsing  technique  would  be  expected  to 
have  in  comparison  to  the  other  techniques. 


In  Section  .1,  the  categories  of  parking  techniques  are  summarized. 
Section  3 discusse:?  the  kinds  of  factors  which  influence  the  choice  of  parsing 
technique  to  be  used  in  designing  a language  and/or  a compiler.  Section  4 
summarizes  some  generalizations  of  non-performance  related  advantages/ 
disadvantages  among  the  various  techniques. 

Z.  Categories  of  Parsing  Techniques 

Below  arc  presented  five  categories  of  parsing  techniques  . For 
each  category  a brief  characterization  of  the  category  is  presented,  together 
with  a brief  discussion  of  variations  within  the  category  currently  in  use. 
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General  techniques.  These  techniques  can  handle  any  context-free  grammar 
including  non-deterministic  and  ambiguous  grammars.  Algorithms  within 
this  category  are  essentially  the  British  Museum  Algorithm,  or  some  variant. 
Consequently,  performance  is  expected  to  be  poor. 


Limited  look-ahead  bottom-up.  This  category  includes  the  least  restrictive 
deterministic  techniques.  This  category  also  permits  the  algorithmic  (auto- 
mated) translation  of  a BNF  description  of  the  grammar  rules  into  a table 
for  driving  the  parsing  algorithm.  (This  automated  parser  building  property 
is  a characteristic  of  most  commonly  used  techniques.  ) These  techniques 
all  involve  looking  ahead  a number,  say  k,  of  lexemes  to  determine  if  the 
top  of  the  stack  completes  a new  phrase,  or  if  the  next  lexeme  should  be  put 
on  top  of  the  stack.  The  most  general  algorithm  of  this  category  is  the 
LR(R).  Variations  such  as  SLR(k)  and  LALR(k)  attempt  to  simplify  the  book- 
keeping tables  in  exchange  for  some  loss  of  generality. 

Precedence  systems.  Precedence  systems  are  also  "bottom  up"  techniques 
which  attempt  to  construct  phrases  from  simpler  elements.  All  are  equiva- 
lent to  special  cases  of  the  previous  category.  There  are  many  variations. 
Conceptually,  one  or  more  precedence  tables  are  used  to  determine  if  the 
top  of  the  stack  completes  a phase,  or  if  the  next  lexeme  should  be  put  on 
top  of  the  stack.  The  grammar  rules  may  be  directly  represented  by  the 
precedence  tables,  rather  (or  in  addition  to)  representing  the  grammar  in 
BNF.  Variations  trade  generality  (in  a number  of  different  dimensions)  for 
table  size  and  complexity. 


Deterministic  top-down  techniques.  These  techniques  are  all  essentially  re- 
cursive techniques  -vhere  a phrase  causes  a recursive  procedure  to  be  in- 
voked to  break  a phrase  into  smaller  constituent  phrases.  Whereas  the 
limited  look-ahead  bottom-up  techniques  are  by  their  nature  deterministic, 
the  top-down  techniques  may  require  considerable  designer  effort  to  ensure 
its  deterministic  character. 


Reductions  analysis  techniques.  These  techniques  are  conceptually  similar 
to  the  bottom  up  techniques,  except  that  the  grammar  is  represented  as  a 
program  for  doing  pattern  matching  on  the  stack  configuration,  rather  as 
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3.  Parser  Selection  Factors 

The  principal  decision  criterion  in  selecting  a parsing  technique  for 
a compiler  is  the  availability  of  support  tools  for  converting  a language 
grammar  representation  into  a functional  parser.  If  a compiler  designer  has, 
for  example,  only  tools  for  LALR(l)  grammar,  then  this  is  the  technique  of 
choice. 

The  reason  the  availability  of  tools  is  a primary  importance  is  that 
a variety  of  "fixes"  are  available  to  handle  those  cases  not  directly  encom- 
passed by  the  parsing  technique  chosen.  These  "fixes"  will  be  discussed 
below.  However,  it  will  be  useful  to  first  note  that  virtually  all  compilers 
use  some  "fixes"  for  situations  that  are  by  their  nature  beyond  the  reach  of 
any  of  the  parsing  techniques  in  common  use. 

Virtually  all  languages  have  one  or  more  aspects  that  are  not  con- 
text-free. For  example,  the  constraints  against  duplicate  or  undefined 
symbols  are  handled  outside  the  grammar  and  parser  by  means  of  auxiliary 
symbol  table  management  mechanisms.  Data  type  matching  may  also  be 
handled  in  the  same  manner  rather  than  expanding  the  grammar  to  include  a 
much  larger  number  of  production  rules.  Lexical  analysis  is  also 
generally  handled  outside  the  parser,  although  it  is  sometimes  included 
by  expanding  the  grammar  with  rules  for  symbol  generation. 

In  view  of  the  accepted  approach  to  go  outside  the  grammar  when  the 
technique  does  not  fit  some  language  requirement,  the  generality  of  a pars- 
ing technique  is  not  a critically  important  selection  criterion.  However, 

"fixes"  using  auxiliary  mechanisms  generally  take  significant  time  and 
energy  to  work  out,  and  reduce  reliability  by  increasing  compiler  complexity. 
Consequently,  if  several  parsing  techniques  are  available,  one  should  probably 
choose  the  most  general  technique. 

Besides  using  an  auxiliary  mechanism  there  are  other  "fixes"  possible 
to  lix  a mismatch  between  language  requirements  and  the  chosen  technique.  If 
the  compiler  design  also  has  control  of  the  language,  then  a slight  change  of  a 
language  construction  may  fix  the  mismatch  problem.  Tf  the  language  is  a "given", 
then  the  possibility  of  modifying  the  grammar  rules  for  describing  the  language 
may  fix  the  situation.  The  introduction  of  additional  intermediate  phrase  con- 
structions might  be  one  such  possible  grammar  level  fix.  If  the  language  is 
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"given"  and  the  grammar  cannot  be  made  to  fit,  then  an  auxiliary  mechanism 
outside  the  parser  might  be  used.  Finally,  changing  the  choice  of  parsing  tech- 
nique to  a different  and  more  general  system  (which  is  not  immediately  available) 
could  be  used  as  a last  resort. 

4.  Advantages  and  Disadvantages  of  Various  Parsing  Techniques 

Presented  below  is  a summary  of  some  generalizations  concerning  the 
advantages  and  disadvantages  of  the  various  parsing  techniques  discussed 
earlier. 

General  Techniques: 

• are  too  slow. 

• have  poor  error  recovery. 

• provide  no  help  in  design. 

• might  be  useful  in  experimental  environments 
with  frequently  changing  language  and  grammars. 

Limited  Look-Ahead  Bottom  Up: 

• are  very  general. 

• permit  fast  performing  implementations. 

• have  storage  requirements  that  vary  greatly  with 
particular  choice  within  category. 

• are  fairly  complex. 

• are  amenable  to  good  error  recovery. 


Deterministic  Top  Down  Techniques: 

• have  excellent  error  recovery  capability. 

• are  somewhat  less  general  than  the  above  techniques, 

• permit  excellent  design  support  aids, 

• permit  very  fast  performing  implementations. 

• include  some  requirements  for  ad  hoc  design  effort 
to  guarantee  deterministic  behavior. 
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Systems : 

are  very  good  for  processing  arithmetic  expressions, 
also  permit  trade-offs  of  generality  for  table  size, 
are  relatively  simple, 
have  good  error  recovery  possibilities. 
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« permit  very  fast  performing  implementations 

• are  moderately  general. 

Reductions  Analysis  Techniques: 

• are  very  general. 

• require  much  ad  hoc  design  effort. 

• can  prr  ‘de  excellent  error  recovery. 

• permit  very  fast  performing  implementations 

• are  hard  to  debug. 


CHAPTER  6 

OPTIMIZATION  ALGORITHMS 


1.  Overview 

This  chapter  discusses  work  performed  in  this  study  in  surveying 
the  literature  on  techniques  for  the  optimization  of  compiler  generated 
object  code.  The  range  of  optimizations  covered  is  quite  broad  and 
includes  all  identified  areas  which  can  possibly  influence  compiler 
performance  in  any  way.  Specific  algorithms  employed  in  optimizing 
compilers  were  not  directly  studied  since  their  implementations  are 
generally  quite  diverse.  Instead,  an  organized  survey  is  presented  of 
classes  of  optimization  which  are  currently  used  in  commercially 
available  compilers,  or  which  are  currently  being  investigated  in  various 
research  environments.  Each  of  these  optimization  classes  is  discussed 
in  terms  of  examples  of  the  application  of  the  techniques  involved,  and 
what  kinds  of  improvement  they  might  produce  in  object  code. 

The  examples  presented  are  in  the  form  of  sequences  of  simple 
statements.  These  may  be  shown  with  a representation  of  distinct  linear 
sequences  of  executable  code  linked  with  branching  flow  above  and 
reconvergence  below.  Each  example  consists  of  an  "original"  sequence 
and  an  "optimized"  sequence  which  reflects  the  effect  of  the  particular 
optimization  being  illustrated. 

In  lieu  of  exploring  specific  algorithms  in  detail,  a thorough 
discussion  is  presented  of  the  kinds  of  preliminary  analysis  activity  required 
by  a compiler  in  order  to  generate  a sufficient  body  of  information  about 
a program  so  that  optimizations  can  be  performed  on  them.  The  kinds 
of  actual  data  manipulation  and  processing  required  to  perform  the 
program  restructuring  and  code  generation  activities  necessary  for 
optimization  are  also  presented. 

Thus,  the  discussion  extends  over  a two  dimensional  conceptual 
space  with  optimisation  classes  as  one  coordinate  and  .activity  classes 
as  the  other.  The  dependencies  of  optimizations  on  analysis  are 
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represented  in  the  form  of  two  matrices  in  Section  6.  The  use  of  a matrix 
form  is  intended  to  clearly  indicate  the  processing  activity  required  to 
support  the  optimizations  being  discussed.  Optimizations  can  be  of  the 
machine  independent  type,  discussed  in  Section  3,  and  the  machine 
dependent  type,  discussed  in  Section  4.  An  Optimization -Analysis  matrix 
is  provided  in  Section  6 for  each  type.  Analysis  classes  can  be  oriented 
toward  data  gathering  and  information  structuring  or  the  actual  perform- 
ance of  the  optimization.  Both  cases  are  discussed  in  Section  5. 

2.  Categories  of  ODtimization  Methods 


Optimizations  fall  into  two  fairly  distinct  categories:  the  machine 
independent  type  and  the  machine  dependent  type.  Machine  independent 
optimizations  tend  to  require  considerable  manipulation  and  restructuring 
of  the  source  program  structure  and  logic.  For  this  reason,  most 
require  an  intermediate  representation  of  source  program  structure. 

There  are  many  such  representations  which  are  more  or  less  equivalent, 
and  for  the  purposes  of  the  present  discussion  it  is  assumed,  without 
appreciable  loss  of  generality,  that  the  intermediate  representation  used  is  a 
tree  structure.  Generally,  machine  dependent  optimizations  attempt  to 
improve  object  code  quality  by  adapting  source  programs  to  a particular 
computer  hardware  environment.  Such  optimizations  generally  do  not 
invol-  e modifications  of  the  tree  structure.  On  the  other  hand,  machine 
independent  optimizations  are  generally  representable  by  specific  changes 
in  the  tree  structure  representation.  Section  3 discussed  machine 
independent  optimizations,  and  Section  4 discusses  machine  dependent 
optimizations. 

3.  Machine  Independent  Optimizations 

Common  expression  elimination.  Common  expression  elimination 
refers  to  the  transformation  cf  programs  to  minimize  the  repeated 
calculation  of  an  expression  which  occurs  in  several  distinct  places. 

The  net  effect  of  applying  this  optimization  is  to  compute  a repeatedly 
used  expression  only  once,  store  its  value  in  a temporary  location,  and 
then  for  all  later  occurrences  of  that  expression,  substitute  the  value 
stored  in  the  temporary. 
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There  are  essentially  two  different  scopes  for  this  optimization: 

» Within  .'ingle  assignment  statements. 

• Across  a multiplicity  of  assignments  statements. 

Both  optimizations  require  modification  of  the  tree  structure  representation 
of  the  source  program  being  compiled,  but  the  first  requires  only  local 
examination  and  manipulation  of  this  representation.  The  second 
necessitates  more  involved  analysis.  Since  the  expressions  of  interest 
span  possibly  a number  of  intervening  assignments,  a flow  analysis  and 
set/used  analysis  is  required  before  constant  values  stored  in  temporaries 
can  be  substituted  for  occurrences  of  these  expressions.  Both  optimiza- 
tions rely  heavily  on  pattern  matching  computations  to  identify  occurrences 
of  the  same  expression,  and  tables  to  hold  expressions  which  potentially 
can  be  optimized.  The  pattern  matching  involves  matching  one  part  of 
the  tree  structure  representation  to  another  part.  The  specific  imple- 
mentation used  for  this  data  structure,  the  matching  algorithms,  table 
organization  and  table  access  methods  all  determine  the  performance  of 
the  common  expression  optimization  processing  within  a compiler. 

An  example  of  common  expression  elimination  is  the  following: 

Original  Optimized 

E = A * B E = A * B 

C = A * B r D — C = E + D 

Equivalent  expression  elimination.  This  optimization  is  for  all 
practical  purposes  identical  to  common  expression  elimination.  The 
most  significant  distinguishing  characteristic  is  that  it  may  be  applied 
over  expressions  which,  at  the  source  code  level,  have  different 
constituent  variables.  In  terms  of  program  logic  (at  the  static  level, 
without  actually  having  to  execute  the  program)  the  optimizer  can 
determine  that  although  such  variables  bear  different  names,  they 
actually  take  values  which  render  their  respective  containing  expressions 
equivalent.  One  means  of  recognizing  this  kind  of  equivalent  results 
from  assignment  propagation  together  with  the  appropriate  substitutions 
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of  values  or  variable  references.  Once  two  different  expressions  have 
been  so  reduced,  the  machinery  of  common  expression  elimination  can 
be  applied,  and  any  potential  optimizations  then  introduced.  Assignment 
propagation  then  is  a precursor  of  some  removal  of  redundancy  in 
expressions  that  differ  at  the  source  code  level,  but  which  are  semantically 
equivalent  under  the  substitution  of  values  or  names  for  certain  variables 
within  these  expressions.  Equivalent  expression  elimination  can  be 
performed  along  with  common  expression  evaluation,  but  is  applicable 
only  after  a preliminary  transformation  which  propagates  known  values 
through  the  program's  tree  structure.  All  considerations  of  scope  bounds, 
flow  analysis,  set/used  analysis  then  apply  in  the  same  manner  as  for 
common  expression  evaluation. 


An  example  of  equivalent  expression  elimination  is  the  following: 

After  Assignment 

Original  Propagation  Optimized 


E = A * B E - A * B E - A * B 

F = B > F = B > F = B 

C = A * F f D C = A * B + D C = E+  D 


Code  motion  out  of  parallel  paths.  Equivalent  code  can  frequently 
be  displaced  from  parallel  paths  through  a program.  Such  paths  can  be 
established  through  an  instance  of  an  IF-THEN -ELSE  construction  in 
which  the  THEN  clause  and  ELSE  clause  constitute  the  program  segments 
which  are  parallel.  Such  parallel  paths  are  also  created  through  GOTO 
statements  involving  variable  indexed  switches.  Such  statements  cause 
flow  to  diverge  from  a common  point  in  a program  (possibly  rejoining 
at  a later  point).  An  analysis  of  program  flow  can  be  performed  which 
identifies  forking  or  reconverging  situations,  which  create  parallel 
paths.  Equivalent  statements  in  such  parallel  paths  may  be  moved  up 
above  the  forking  point  or  belaw  the  point  of  reconverger.ee  (if  one  exists). 
The  direction  in  which  code  can  be  moved  is  dictated  by  performing  a 
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If  no  variables  referenced  as  data  sources  within  a statement  are 
altered  between  the  forking  point  and  the  occurrence  of  the  statement, 
then  that  statement  can  be  removed  from  the  parallel  paths  and  established 
above  the  forking  point.  Thus  the  work  done  by  the  statement  is  per- 
formed only  once,  rather  than  on  each  path.  On  the  other  hand,  if 
variables  set  by  a statement  are  not  referenced  below  the  statement  up 
to  the  reconvergence  point  (if  one  exists),  then  that  statement  can  be 
moved  below  the  reconvergence  point. 

This  optimization  relies  heavily  upon  flow  analysis  to  identify 
the  straight  line  sequences  of  executable  code,  the  forking  points  and 
the  reconvergence  points.  Once  this  has  been  done,  pattern  matching 
is  used  to  isolate  those  constructions  which  potentially  may  be  moved 
up  or  down  from  parallel  paths.  Whether  such  motion  of  code  is 
performed  depends  on  the  results  of  set/used  analysis.  Code  can 
actually  be  moved  only  if  the  conditions  above  are  met  and  then  only  in 
the  directions  indicated. 

An  example  of  code  motion  out  of  parallel  paths  is  the  following: 


Original  Optimized 


Invariant  computations.  Invariant  computation  optimizations 
also  result  in  code  motion,  but  of  a special  kind.  This  form  of  optimiza- 
tions attempts  to  improve  the  object  code  resulting  from  iteratively 
controlled  loops,  and  equivalent  forms,  by  moving  constant  computations 
outside  loops  where  they  are  evaluated  only  once.  The  requirement  for 
performina  this  optimization  is  a flow  analysis  to  identify  and  bound 
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the  iterative  loop,  and  an  associated  set/used  analysis  to  determine  those 
constructions  which  can  be  calculated  above  the  loop,  and  then  referenced 
as  values  of  temporary  locations.  The  same  facilities  employed  in  code 
motion  optimization  can  be  applied  to  move  invariant  code  upward  outside 
of  loops. 
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Dead  variable  elimination.  Dead  variable  elimination  involves 
the  recognition  and  elimination  of  variables  which  are  set  but  not  used, 
or  which  are  declared  but  never  referenced.  Essentially,  a variable 
which  is  never  referenced  can  be  deleted.  Furthermore,  the  deletion 
of  certain  variables  in  a program  may  be  sufficient  to  trigger  the 
deletion  of  other  variables  which  may  have  been  used  to  produce  a 
right  hand  side  value  for  that  variable  in  an  assignment.  A set/used 
?-nalysis  is  sufficient  to  support  this  optimization.  This  set/used 
analysis  can  be  performed  either  before  other  optimizations,  or  after 
all  other  optimizations.  If  the  former,  then  each  subsequent  iteration 
of  assignment  propagation  should  update  in  an  appropriate  manner  the 
results  of  the  set/used  analysis.  The  actual  work  of  the  optimization 
is  the  maintenance  of  the  set/used  data,  usually  in  conjunction  with  the 
compiler's  symbol  table.  Once  this  work  is  done,  the  optimization  is 
made  effective  during  the  storage  allocation  function  of  the  compiler. 
(A  description  of  the  storage  allocation  function  is  presented  in 
Section  2 of  Chapter  3.  ) 


An  example  of  dead  variable  elimination  is  the  following: 


Original 
A = 10 

B - A > 

C = B + D 


After  Assignment 
Propagation 

A = 10 

B = 10  > 

C = 10  + D 


Optimized 


C = 10  + D 


Redundant  statement  elimination.  This  optimization  involves  the 
removal  of  st3.tcmsiits  v/hich  hstvs  no  of  foot  upon  th.6;  oxocution  of  ^ 
program.  Such  statements  fall  into  two  classes: 
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• Those  which  are  apparent  at  the  source  code  level. 

• Those  which  result  from  an  assignment  propagation  pass. 


This  optimization  is  dependent  only  upon  flow  analysis  and  set/used 
information.  Assignments  of  values  to  variables  not  used  before  they 
are  reset  with  new  values  can  be  eliminated.  Such  operations  are  most 
easily  performed  on  the  tree  structure  representation. 

Variable  merging.  Variable  merging  is  a form  of  space  saving 
optimization.  The  storage  allocations  to  variables  which  are  never  used 
concurrently  are  overlayed.  Flow  analysis  and  set/used  analysis  is 
required  to  make  the  determination  of  the  active  or  inactive  state  of  a 
variable  in  various  segments  of  a program.  Inactive  variables  become 
candidates  for  storage  sharing,  provided  their  set/used  information 
indicates  their  storage  allocations  can  be  safely  reused.  The  optimization 
becomes  effective  during  storage  allocation. 

Formula  transformation.  Formula  transformation  is  one  of  the 
more  complex  categories  of  program  optimization.  There  are  many 
different  transformation  which  can  be  applied,  and  almost  any  kind  of 
transformation  can  be  considered  {short  of  actually  changing  the 
algorithm). 


• Expret  sjon  reordering  is  usually  dene  as  a space  saving 
optimization  by  reducing  the  use  of  temporary  locations 
required  to  evaluate  an  arbitrary  expression.  Some 
labeling,  counting,  and  interrogation  of  the  tree 
structure  representation  is  required  to  determine 
reorderings  that  do  indeed  improve  usage  of  temporary 
locations.  However,  the  effect  of  the  optimization  is 
best  seen  in  the  resulting  object  code  produced  as 
illustrated  in  the  example  below.  The  following  is  an 
example  of  expression  reordering; 


Original 


Optimized 


= A + B 

+ c * 

D > 

E = C * D 

+ A 

+ B 

LOAD 

A ^ 

LOAD 

C 

N 

ADD 

B | 

MPY 

D 

STO 

T | 

/DD 

A 

LOAD 

C 

\ compiler 

ADD 

B 

t 

^ compiler 

MP1 

D 

output 

STO 

E 

output 

ADD 

T 

STO 

E 

) 
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Factoring  involves  essentially  algebraic  manipulation  of 
the  source  program  at  the  intermediate  representation 
level.  It  relies  heavily  on  pattern  matching  techniques, 
and  the  interrogation  of  fixed  tables  of  transformations 
which  may  potentially  be  applied. 

The  following  is  an  example  of  factoring: 


Original 


Optimized 


D=A*B+A*C 


D = A * (B  + C) 


Strength  reduction  is  primarily  concerned  with  the  optimi- 
zations of  calculations  within  iterative  loops.  Operations 
involving  iterative  computation  (e.  g.  multiplication, 
exponentiation,  factorials,  etc.  ) can  be  objects  of  this 
form  of  formula  transformation  optimization. 

The  following  is  an  example  of  strength  reduction: 


Original 


Optimized 


FOR  I = 1,  N 
BFGIN 

L = K * I + M 


Z = K 

FOR  I = 1,  N 
BEGIN 
L = Z + M 
Z = Z + K 
END 


Constant  evaluation  generates  values  for  expressions 
involving  only  constants  at  compile  time.  Simple  pattern 
matching  to  isolate  the  constants  and  associated  operators 
is  sufficient  to  determine  opportunities  for  this  optimiza- 
tion. 

The  following  is  an  example  of  constant  evaluation: 


Original 


Optimized 


R = 2.  * 3.  1415926  — R = 7.  2831852 

Low  power  exponentiation  changes  exponentiation  by  a 
low  integer  power  into  a sequence  of  multiplications. 

In  the  machine  independent  realization  this  optimization 
it  is  performed  as  follows,  first,  pattern,  matching  Li 
the  tree  structure  representation  is  performed,  then  a 
transformation  is  made  of  the  representation  of  the 
exponentiation  expression  into  a representation  for  a 
sequence  of  multiplications. 
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The  following  is  an  example  of  low  power  exponentiation: 

Original  Optimized 

X = Y **  5 5=-  T1  = Y*Y 

T2  = T1  * T1 
X = T2  * Y 

Subroutine  closing.  Subroutine  closing  is  similar  to  code  motion. 
However,  the  straight  line  program  segments  affected  need  not  be 
parallel.  For  this  optimization,  identical  groups  of  statements  which 
appear  in  distinct  areas  of  a program  are  "extracted",  and  a single  copy 
established  as  a closed  subroutine.  Calls  to  this  closed  subroutine 
replace  the  statement  groups.  Thus  a space  savings  results  as  compared 
with  the  unoptimized  program.  This  transformation  is  supported  by  flow 
analysis  and  pattern  matching  to  isolate  the  code  segments  of  interest. 

A major  modification  of  the  intermediate  representation  is  required  to 
physically  restructure  a program  in  this  fashion. 

The  following  is  an  example  of  subroutine  closing. 

Original  Optimized 


« 

S 

n 


« 

[call  p 
[call  p 


i1! 

2 l This  sequence 
! ) becomes  subroutine 

S J P- 
n s 
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Retargeting  of  jumps.  Retargeting  of  jumps  is  one  of  the  conceptually 
simpler  optimizations,  and  it  can  be  performed  either  as  a machine 
dependent  or  machine  independent  optimization.  For  machine  independent 
retargeting,  a flow  analysis  is  used  to  reveal  those  transfers  of  control 
which  pass  through  one  or  more  other  branch  statements  to  reach  a 
particular  program  statement.  Then  the  original  branch  statement  is 
simply  retargeted  to  the  destination  program  statement  to  eliminate 
intervening  branches.  (Machine  dependent  retargeting  is  discussed 
under  Section  4). 

The  following  is  an  example  of  retargeting  of  jumps: 

Original  Optimized 


I 


GOTO  LI 


GOTO  L2 


LI:  GOTO  L2 


LI:  GOTO  L2 


L2: 


L2: 


I 


4.  Machine  Dependent  Optimizations 

Minimization  of  memory  references.  Minimi  jation  of  memory 
references  is  a generalization  of  the  register  allocation  problem. 

Registers  on  almost  all  machines  can  be  referenced  and  altered  at  rates 
significantly  faster  than  main  memory  locations.  This,  and  the  fact  that 
the  majority  of  machines  require  variables  to  be  held  in  registers  in 
order  to  be  operated  upon,  make  it  very  desireable  to  minimize  references 
to  memory  in  order  to  reduce  execution  time.  The  common  approach  is 
to  allocate  a target  machine's  registers  in  such  a way  as  to  minimize  direct 
reference  to  main  memory  for  the  values  of  variables.  For  machines  with 
only  one  or  two  operational  registers,  the  whole  problem  of  register 
allocation  is  of  little  consequence.  Hov/ever,  for  machines  with  many 
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operational  registers,  where  such  registers  may  have  specific  usage 
characteristics,  sutfh  as  indexing,  fixed  point,  and  floating  point,  the 
problem  can  be  quite  complex. 

Several  different  forms  of  this  optimization  may  constrain  the 
register  allocation  process.  One  form  merely  attempts  to  keep  as 
many  registers  busy  as  possible  during  the  evaluation  of  complicated 
arithmetic  expressions  since  this  will  reduce  stores  and  retrievals  of 
values  for  variables  and  temporaries.  Another  form  attempts  to  bind 
certain  variables  to  registers  across  loops,  in  order  to  keep  frequently 
i and  periodically  referenced  values  readily  accessible  in  machine 

registers.  Yet  another  form  is  concerned  with  addressing  which  is 
dependent  on  base  register  and  index  register  usage. 

Register  allocation,  as  a means  of  minimizing  memory  references, 
is  a complicated  process  resulting  in  algorithms  which  can  become  quite 
complex.  However,  simplified  heuristics,  such  as  assignments  based 
on  least  recently  used  rules,  can  achieve  results  which  are  respectably 
close  to  optimal  at  a much  lower  computational  cost.  Most  sophisticated 
algorithms,  especially  those  which  operate  over  loops,  require  flow 
analysis  and  set/used  ana.ysis  to  provide  sufficient  information  about 
the  source  program  to  allow  efficient  register  allocation. 

Elimination  of  redundant  stores.  Elimination  of  unnecessary 
stores  attempts  primarily  to  isolate  and  remove  store  instructions  which 
move  values  from  registers  to  variables  and  temporary  locations.  There 
are  two  techniques  for  achieving  this  elimination.  The  fii  •*  requires  that 
the  compiler  have  complete  information  about  the  reference  and  usage 
patterns  of  variables  during  the  code  generation  operations  on  arithmetic 
i or  Boolean  expressions.  Using  this  information  during  the  register  allocation 

• pass,  it  is  possible  to  determine  just  when  the  value  assigned  to  a register 

l is  no  longer  needed.  Rather  than  force  a store  of  the  registers  value  to  a 

temporary  when  that  register  must  be  freed  for  other  use,  the  register  is 
simply  reassigned  and  the  value  forgotten.  The  second  method  involve, 
using  a simpler  procedure  requiring  less  compl-  te  knowledge  of  the  reference 
patterns,  and  a correspondingly  simpler  register  allocation  algorithm.  A 
heuristic  approach  is  used  for  the  allocation  of  registers,  and,  as  tne  code 
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generation  progresses,  special  usage  tables  ure  maintained  which  are  sub- 
sequently used  in  a post-processing  pass  to  isolate  and  remove  redundant 
stores. 

Retargeting  of  jumps.  Retargeting  of  jumps  can  be  performed 
during  object  code  post-piocessing.  This  requ:red  following  chains 
of  transfer  instructions,  and  then  shortening  the  chains  to  direct 
branches. 

Low  power  exponentiation.  Exponentiation  by  low  integer  powers 
can  be  detected  and  efficiently  processed  during  the  machine  dependent 
code  generation  process.  The  exponentiation  code  generator  can  examine 
the  exponent  expression,  determine  its  form,  and  if  appropriate, 
generate  an  appropriate  sequence  of  multiply  instructions,  thereby 
avoiding  the  otherwise  costly  call  to  a library  exponentiation  routine. 

Use  of  special  instructions.  Code  generators  which  attempt  to 
use  special  instructions  available  on  the  target  machine  can  achieve  a 
considerable  improvement  in  the  object  code  they  produce,  though  such 
improvements  are  generally  quite  local  in  their  nature.  This  optimization 
can  be  accomplished  one  of  two  ways.  Either  special  machine  dependent 
code  generators  cr  tables  can  be  used  which  recognize  and  respond  to 
the  special  situations  in  which  special  instructions  can  be  used,  or 
object  code  pattern  matching  can  be  done  during  general  object  code 
post-processing,  and  the  appropriate  object  code  substitutions  made  at 
that  time. 

The  following  are  two  examples  of  the  use  of  special  instructions: 

• Shifts  anc1  increments  may  be  substituted  for  certain 

machine  operations  to  more  efficiently  achieve  a standard 
program  operation,  which  would  otherwise  require  more 
code  or  slower  code  to  be  generated.  Fairly  transparent 
examples  include  the  use  of  SHIFT  instructions  to 
perform  integer  division  and  multiplication  by  powers  of 
two,  and  INCREMENT  instructions  to  achieve  addition 
by  one.  Such  substitutions  are  generally  handled 
by  special  logic  in  the  code  generation  process. 
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» Special  operations  and  memory -to -memory  operations 
availaole  on  some  machines  are  largely  unexplored  in 
optimizations  currently  practices.  However,  some 
compilers  do  generate  code  for  such  machines.  The 
identification  of  opportunities  for  such  optimizations 
is  easiest  to  implement  by  analysing  the  tree 
structure,  representation  of  the  source  program  during 
machine  dependent  code  generation. 

Use  of  special  data  reference  modes.  Data  organizations  in 
current  languages  can  be  quite  complex,  with  elementary  items 
organized  into  data  structures  with  possibly  many  hierarchical  levels. 
Referencing  such  structures  or  parts  of  structures  present  an  opportunity 
for  optimization  at  both  storage  allocation  and  data  referencing  time. 

The  following  are  three  examples  of  the  use  of  special  data 
reference  modes: 

• Variable  precision  is  a’’ocated  by  many  compilers;  they 
maintain  sufficient  information  abou.  he  types  and 
precision  of  data  items  to  allow  the  storage  allocation 
pass  to  determine  whether  or  not  an  item  should  be 
stored  in  a byte,  halfword,  or  double  word  location. 

For  instance,  some  systems  restrict  loop  and  iteration 
variables  to  occupy  half  word  locations  unless  explicitly 
declared  to  be  of  greater  precision. 

• Packing  and  unpacking  of  data  items  is  simplified  by 
machines  which  have  facilities  for  accessing  variable 
iengch  bytes,  or  which  allow  referencing  of  partial 
word.-  using  special  modes  or  masks  to  discard  portions 
of  words  which  are  not  needed. 

• Immediate  and  mcirec ! acccs.-i  modes  are  of  great 
utility  in  compiler  generated  code,  in  accessing 
simple  constants  and  referencing  based  or  pointer 
referenced  data. 


n.  Optimization  Activities 

Optimization  activity  within  compilers  can  be  organized  into 
two  fairly  general  categories.  The  first  involves  all  those  algorithms, 
processing  tasks,  and  data  manipulations  which  are  preparatory  to  the 
actual  performance  of  optimizations  such  as  we  have  discussed  glove. 


This  includes  the  preliminary  analysis  of  program  structure,  and  the 
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construction. and  maintenance  of  necessary  data  and  associated  tables  to 
support  these  optimizations.  The  second  category  includes  those 
operations  by  which  optimizations  of  a program  are  realized.  These 
can  be  organized  into  two  distinct  classes:  (1)  those  which  require 
modification  of  the  program  at  the  level  of  the  tree  structure  represen- 
tation, and  (2)  those  which  can  be  achieved  through  the  use  of  special 
machine  dependent  code  generation  elements  or  table  entries.  Most  of 
the  former  are  machine  independent  optimizations,  which  are  considerably 
influenced  by  the  actual  instruction  repertoire  of  the  target  machine. 


Flow  analysis.  Flow  analysis  is  performed  on  a program  to 
develop  several  kinds  of  useful  information.  The  primary  result  is  a 
static  representation  of  the  straight  line  executable  sequences  and  the 
dynamic  control  paths  within  a program.  For  the  purposes  of  the 
present  discussion,  straight  line  executable  sequences  are  called 
"blocks".  Secondary  information  includes  identification  of  dominance 
relationships  among  blocks,  parallel  control  paths  and  the  like. 


Flow  analysis  is  performed  by  taking  into  consideration  the 
influence  on  the  flow  paths  of  various  language  elements.  Some  simple 
examples  of  such  considerations  are  the  following: 

FOR  statements  represent  iterative  loops. 

IF-THEN  (-ELSE)constructions  create  parallel  paths. 


Conditional  GOTO's  create  either  parallel  paths  or 
iterative  loops.  (The  determination  of  which  is  well 
defined  but  somewhat  complex.  ) 


Labeled  statements  which  are  the  objects  of  GOTO's  and 
which  are  executable  in  sequence  from  preceding 
statemen.5  represent  reconvergence  points  of 
parallel  paths,  or  possibly,  loop  constructions. 


BEGIN- END  pairs  bounding  no  GOTO's  or  IF-THEN - 
(ELSE)  constructions,  or  labeled  statements  constitute 
boundaries  of  a block  (or  a constituent  part  of  a block). 


The  results  of  such  analysis  is  of  great  use  in  many  optimizations 


4*  k — x t ^ ^4  A — VA  4-  A — "v  A f A %•  ' A % r a # A — A ^ ^ A A -A  i-  /A  a M a 4 A /.  —A  A A «A  4-  A M ' * - —A  A 

uiat  i-w  |^wi  i m tuvvuu.buv  \j  x o '.o.ontt/Ui.  gtywi/n, 


The  hierarchical  dominance  relationships  among  statement  blocks  can 


85 


ii 


1 nifri  -i 


K 

S* 


l! 


’"‘■lgffl!H»,y ijgffy,.*.1  -t*..’*-?  'iiwwj.'ji  '.tt'J rzifZ'inr: 


be  determined  as  well,  allowing  some  optimizations  of  register  allocation 
across  block  boundaries.  This  information  is  represented  as  block 
dominance  graphs,  and  indicates  what  statement  groups  are  subordinate 
to  others  within  control  flow  paths.  Optimizations  proceed  from  innermost 
blocks  to  outermost  blocks. 

Flow  analysis  information  is  most  conveniently  represented  in 
the  form  of  directed  graphs  with  blocks  of  statements  as  edges,  and 
branches  and  control  receiving  points  as  nodes.  For  the  purposes  of 
determining  the  connectivity  of  blocks,  matrix  forms  are  also  used. 

An  initial  adjacency  matrix,  giving  those  blocks  which  can  be  reached 
within  a single  control  step,  under  repeated  self  multiplication  is 
sufficient  to  determine  which  blocks  are  adjacent  in  any  number  of 
steps. 

Set /used  analysis.  Set/used  information  is  collected  for  each 
variable  declared  in  a program.  Uses  are  recorded  whenever  a variable 
appears  on  the  right  hand  side  of  an  assignment  statement,  as  an 
argument  in  a subroutine  call,  or  in  an  expression  which  must  be 
evaluated  subordinate  to  another  statement.  Sets  are  recorded  for  a 
variable  whenever  it  appears  on  the  left  hand  side  of  an  assignment 
statement,  as  an  argument  in  a subroutine  call  or  as  an  iteration  control 
variable.  In  program  languages  which  allow  pointers  to  refer  to 
variables,  any  usage  of  a pointer  to  reference  data  also  counts  as  set/ 
use  references  for  all  variables  to  which  the  pointer  refers. 

Set/used  information  can  be  collected  relative  to  control  flow 
structure,  including  block  dominance  relationships.  Such  information 
can  be  easily  represented  in  list  form,  with  each  variable  "owning"  a 
list  of  source  program  statements  in  which  it  is  set,  and  a corresponding 
list  of  statements  in  which  it  is  used. 


Tree  structure  representation  pattern  matching.  Pattern  matching 
on  the  tree  structure  representation  presents  a fairly  difficult  problem 
fro  the  romniler  designer.  While  such  analysis  could  nroceed  easilv 
using  node  by  node  comparison  on  a tree  structure,  considerations  of 
efficiency  require  greater  attention  to  organization  and  execution. 
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Pattern  matching  on  tree  structures  can  be  of  a local  nature 
(constrained  to  a single  arithmetic  statement).  Techniques  for  speeding 
up  such  matching  and  searching  include  the  use  of  hashing  techniques 
and  the  insertion  of  special  information  at  certain  nodes  within  the  tree. 

It  is  also  possible  to  take  advantage  of  host  machine  characteristics  in 
representing  tree  structures  and  searching  for  specific  bit  patterns 
during  the  matching  process.  For  instance,  using  a single  or  double 
word  to  hold  an  operand -operator-operand  structure  can  yield  considerable 
improvement  in  search  times. 

Pattern  matching  at  the  tree  structure  representation  is  essential 
to  carry  out  optimizations  based  on  common  expression  or  subexpression 
detection.  Formula  transformation  also  requires  such  techniques  to 
isolate  node  structures  which  have  simpler  or  more  efficient  expressions. 
Pattern  matching  can  be  applied  directly  to  the  original  tree,  or  to  the 
tree  resulting  from  an  iteration  of  assignment  propagation. 

Tree  structure  representation  processing.  Some  additional 
processing  of  the  tree  structure  can  be  of  utility  in  facilitating  certain 
optimizations.  For  expression  reordering,  labeling  the  tree  for  node 
depth  is  convenient  in  signaling  when  a construction  can  be  rearranged 
to  minimize  the  generation  of  temporary  locations  in  its  evaluation. 

Object  code  pattern  matching.  Detecting  special  patterns  in 
object  code  produced  by  a compiler  may  be  performed  either  as  part 
of  a separate  general  object  code  post-processing  pass,  or  in  a limited 
fashion  as  part  of  a peephole  object  code  post-processor.  If  part  of  a 
separate  pass,  then  global  occurrences  of  special  instruction  sequences 
are  sought,  as  well  as  opportunities  for  reordering  evaluations,  constant 
evaluation,  retargeting  jumps,  and  many  other  special  cases  of  machine 
independent  optimizations.  Such  searches  can  be  implemented  as  special 
tests,  or  they  can  be  driven  by  a sophisticated  finite  state  machine  which 
can  be  constructed  to  detect  rather  complex  object  code  patterns  and 
trigger  their  reduction. 
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If  the  pattern  matching  is  performed  as  part  of  a peephole  object 
code  post-processor,  then  the  range  of  object  code  over  which  matching 
is  attempted  is  limited  to  the  contents  of  a relatively  small  core  resident 
buffer. 
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Assignment  propagation.  Assignment  propagation  falls  quite 
appropriately  in  the  class  of  preparatory  optimization  work.  It  can 
potentially  induce  sufficient  equivalence  in  form  to  allow  pattern  matching 
driven  optimizations  to  proceed  where,  otherwise,  they  would  have 
been  blocked  by  superficial  source  program  differences.  (See  discussion 
of  equivalent  expression  elimination  in  Section  3.  ) 


Iteration.  Several  iterative  preparatory  and  optimization  work 
passes  are  possible.  For  example,  an  iteration  might  involve  an 
assignment  propagation  pass  followed  by  code  motion,  redundant  state- 
ment elimination,  common  expression  elimination  and  dead  variable 
elimination. 
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Tree  restructuring.  Restructuring  of  the  intermediate  representation 
is  required  to  support  many  machine  independent  optimizations.  Res  true  tu-ing 
includes  the  operations  of  eliminating  nodes  in  the  tree  structure, 
replacing  node  sequences  with  equivalent  ones,  altering  node  linkages 
and  so  on.  Most  of  tnese  restructurings  are  generally  controlled  by 
specific  optimization  algorithms  and  are  local  in  nature,  involving  only 
a small  number  of  nodes. 

Major  tree  restructuring.  Alternate  of  program  structure  on  a 
major  scale  is  rarely  required,  but  in  the  instance  of  subroutine  closing, 
considerable  code  motion  and  elimination  may  occur,  which  would  have 
such  an  effect. 

Space  allocation  adjustment.  Allocation  of  storage  to  variables 
generally  leaves  the  intermediate  representation  unchanges.  Most 
alterations  required  by  variable  elimination  and  merging  can  be  easily 
and  simply  indicated  with  a program's  associated  symbol  table. 
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Object  code  post-processing.  Post-processing  of  object  code 
generated  by  the  compiler  is  performed  for  a number  of  reasons. 

Simple  examples  include  removal  of  redundant  LOAD -STORE  or 
STORE-LOAD  pairs,  and  the  transformation  of  certain  code  sequences 
to  more  efficient  ones.  In  conjunction  with  pattern  matching  algorithms, 
more  complex  optimizations  can  be  performed,  such  as  movement  of 
invariant  code.  However,  code  motion  of  any  sort  requires  considerably 
more  work  at  this  stage  than  at  the  global  machine  independent  optimiza- 
tion stage  when  the  function  operates  on  the  tree  structure  representation. 

Special  code  generators.  Code  generation  routines,  which  are 
engineered  for  optimizing  certain  local  constructions  for  a given  target 
machine,  fall  into  this  class.  The  primary  optimization  is  to  employ 
special  machine  instructions  to  achieve  standard  operations  with 
improvements  in  speed  or  space  utilization.  Simple  examples  include 
the  use  of  shifts  for  multiplication  by  powers  of  two,  increments  for 
addition  or  subtraction  by  one,  and  immediate  data  modes  to  reference 
jj  constants.  Such  code  generation  functions  can  operate  directly  from 

| tree  structure  representations,  or  those  representations  can  have  been 

augmented  with  special  information  to  signal  constructions  which  are 
candidates  for  special  techniques.  This  special  information  would  have 
been  placed  into  tne  tree  structure  representation  (or  into  auxiliary 
i data  structures)  duiing  general  machine  independent  optimization. 

6.  Matrices  of  Optimizations  vs.  Required  Analysis 

i Two  matrices  are  presented  below.  The  first  (Figure  8) 

[ summarizes  the  preparatory  work  and  optimization  work  required  to  bring 

f about  the  various  machine  independent  optimizations  discussed  in 

j Section  3.  The  second  matrix  (Figure  9 ) presents  a similar  summary 

l with  respect  to  the  machine  dependent  optimizations  discussed  in 

Section  4. 


PREPARATORY  WORK  OPTIMIZATION  WORK 
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Figure  8.  Matrix  of  Preparatory  and  Optimization 
Work  Required  for  Machine  Independent 
Optimizations 
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Figure  9.  Matrix  of  Preparatory  and  Optimization  Work  Required  for 
Machine  Depend  ,nt  Optimizations. 
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CHAPTER  7 


CODE  GENERATION  ALGORITHMS 


1.  Overview 

This  chapter  discusses  various  methods  of  code  generation  used  in 
compilers.  The  range  of  code  generation  methods  used  is  quite  small  as 
compared  with  optimization,  table  look-up,  or  parsing  algorithms.  In  fact, 
there  are  only  three  distinct  methods  used: 

• Directly  Programmed  Code  Generators. 

• ‘ Macro  Organized  Code  Generators. 

• Table  Driven  Code  Generators. 

In  Section  2,  a paradigm  architecture  for  code  generation  is  described. 
This  architecture  describes  an  organization  for  the  machine  independent  part 
of  a code  generating  phase,  which  follows  a parsing  phase.  The  three  methods 
of  code  generation  indicated  above  constitute  alternate  methods  of  including 
the  machine  dependent  parts  of  a code  generator.  The  place  in  which  each 
of  the  above  three  methods  of  code  generation  fits  into  the  paradigm  is  also 
presented  in  Section  2.  Then  in  Sections  3,  4,  and  5,  each  of  these  three 
methods  will  be  discussed  from  the  point  of  view  of  overall  advantages  and 
disadvantages.  One  clear  conclusion  can  be  summarized  here: 

• There  is  no  definite  advantage  or  disadvantage  with  respect 

to  compiler  performance  in  comparing  the  three  methods. 

This  conclusion  for  code  generation  is  the  same  as  that  found  for 
parsing  algorithms  and,  to  some  extent,  for  table  look-up  algorithms.  The 
choice  of  an  algorithm  in  designing  a compiler  is  generally  made  for  other 
than  compiler  performance  considerations.  Consequently,  compiler  per- 
formance is  best  determined  by  direct  measurement  rather  than  by  looking 
into  its  architecture  and  algorithms.  With  respect  to  optimization  algorithms, 
for  example  (see  Chapter  6),  algorithms  are  generally  selected  to  provide 
a desired  balance  between  compiler  performance  and  object  code  performance. 
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Paradigm  for  a Code  Generator  Architecture 

The  code  generation  architecture  described  below  includes  what  is 
more -or -less  the  overall  functional  activities  performed  by  a code  generation 
phase  of  a compiler.  Although  there  are  unlimited  variations  possible,  the 
essential  elements  would  all  have  to  be  present  in  any  architecture  used. 

The  purpose  of  describing  a single  architecture  as  a paradigm  for  code 
generation  architectures  generally,  is  to  provide  a basis  of  comparison  of 
how  the  three  specific  methods  indicated  in  Section  1 fit  into  a code  generation 
architecture. 

The  architecture  described  assumes  a separate  code  generation  phase 
following  a parsing  phase.  The  parsing  phase  is  assumed  to  produce  a binary 
tree  structure  repsentation  of  the  source  language  program,  and  the  code 
generation  phase  walks  through  the  nodes  of  the  tree  to  gather  information 
used  to  generate  object  code.  In  a one  pass  compiler,  some  state  informa- 
tion available  from  the  parser  could  be  used  by  the  cede  generation  activity; 
in  a multi-pass  compiler,  this  information  would  normally  have  to  be 
recreated  if  it  were  needed.  Furthermore,  in  a one  pass  compiler,  the 
parser  does  not  generate  nodes  of  a tree  as  output;  rather  the  parser  pro- 
ductions directly  call  upon  the  node  type  related  code  generating  procedures 
(denoted  below  as  PROG-A-1,  PROG-A-2,  and  PROG-A-3)  as  the  parsing 
activity  discovers  appropriate  productions  are  to  be  applied.  However,  these 
distinctions  are  relatively  unimportant  from  the  point  of  view  of  providing  a 
single  context  for  comparing  the  three  code  generation  methods  listed  in 
Section  1. 

At  the  completion  of  the  parsing  phase,  the  following  information  is 
assumed  to  be  included  in  the  tree  structure  representation  of  the  program 
being  compiled.  At  each  node  of  the  tree  there  is  specific  information, 
more -or -less  related  to  particular  syntactic  elem  .nts  in  the  sotirce  language, 
as  well  as  the  linkage?  to  the  other  nodes  which  define  the  tree  structure. 

Let  us  refer  to  the  node  specific  information  simply  as  the  node  type.  Let 
us  denote  an  arbitrary  node  of  the  tree  as  A.  Let  B and  C be  the  left  and 
and  right  descendants  of  A respectively.  (Note:  either  or  both  of  B and  C 
may  be  NULL  nodes). 
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We  assume  a recursive  tree  walking  program,  TW  which  operates  as 
follows.  When  TW  is  invoked,  a pointer  to  a node,  say  is  passed  as  an 
argument.  TW  thus  performs  the  following  sequence  of  steps: 

• Call  a program  associated  with  the  node  type  of_A,  say  PROG- A- 1. 
(PROG-A-1  may  be  NULL  in  which  case  this  call  is  skipped). 

• Extract  the  pointer  to  JB.  If  not  NULL,  call  TW  with  the  pointer 
to  B as  argument. 

• Call  a second  program  associated  with  node  type  A,  say  PROG-A-2, 
(PROG-A-2  may  be  NULL,  in  which  case  this  call  is  skipped). 

• Extract  the  pointer  to  If  not  NULL,  call  TW  with  the  pointer 
to  C as  argument. 

• Call  a third  program  associated  with  node  type say  PROG-A-3. 
(PROG-A-3  may  be  NULL,  in  which  case  this  call  is  skipped). 

The  activity  of  the  entire  code  generation  phase  can  be  considered 
the  result  of  a single  call  to  TW  with  a pointer  to  the  base  of  the  entire  tree 
as  argument. 

Note  that  in  the  above  sequence  of  steps,  TW  does  not  take  into  account 
any  state  information.  All  tests  of  state  and  changes  of  state  are  handled  in  the 
programs  PROG-A-i,  PROG-A-2  and  PROG-A-3.  Also  note  that  there  are 
relatively  many  distinct  such  programs,  possibly  as  many  as  three  for  each 
node  type,  which  would  correspond  to  three  for  each  syntactic  element  of  the 
language.  It  is  certainly  most  likely  that  the'  will  be  at  least  one  non-null 
program  for  each  node  type.  We  will  next  look  at  the  functional  elements  of 
each  such  program. 

Each  node  type  related  program  consists  of  a machine  independent 
part  and  a machine  dependent  part.  The  machine  independent  part  interrogates 
information  available  at  the  node  and  state  information;  branches  are  taken 
and  state  information  may  be  updated.  Each  flow  path  of  the  machine  inde- 
pendent part  may  lead  to  a distinct  machine  dependent  part.  The  machine 
dependent  parts  set  up  parameters  specific  to  the  outputting  of  object  code 
which  constitutes  the  final  compiled  version  of  the  program  being  compiled. 
The  specific  object  code  that  is  generated  depends  on  the  state  information 
set  up  by  the  machine  independent  part,  as  well  as  the  specifics  of  the  target 
machine  for  which  the  output  code  is  intended.  It  is  these  machine  dependent 
parts  of  each  node  type  related  program  thatn  can  be  implemented  by  means  of 
one  of  the  three  methods  listed  in  Section  1. 
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In  summary,  the  machine  independent  part  is  (generally)  implemented 
as  direct  code  involving  conditional  branching,  testing  of  state  information, 
and  updating  state  information.  * The  machine  dependent  part  is  implemented 
in  one  of  three  ways  (direct  code,  macros,  table  driven  interpreter).  It  tests 
state  information  and  causes  the  desired  output  code  to  be  generated. 

3.  Directly  Programmed  Code  Generators 

If  the  machine  dependent  parts  of  the  node  type  related  programs  are 
implemented  as  direct  code,  then  each  such  part  of  this  code  will  consist 
of  a sequence  of  steps  as  follows: 

• Set  up  parameters 

• Call  Object  Code  Output  primitive. 

• Set  up  parameters . 

• Call  Object  Code  Output  primitive. 


• Set  up  parameters. 

• Call  Object  Code  Output  primitive. 

Note  that  there  is  a single  primitive  invoked  several  times  with  different 
parameters. 

The  principal  advantages  of  this  method  is  the  simplicity  of  preparing 
the  machine  dependent  parts  of  the  program.  There  is  no  requirement  to 
interface  with  a Macro  processor;  consequently,  it  is  not  necessary  to  be 
concerned  with  the  special  problems  associated  with  the  use  of  distinctly 
different  Macro  language  (rather  than  the  language  in  which  the  rest  of  the 
compiler  is  coded).  Furthermore,  the  computer  time  required  to  run  the 
compiler  code  through  the  Macro  processor  is  saved.  Overall,  the  direct 
code  method  should  be  less  expensive  to  use  in  implementing  a compiler 
and  the  resulting  compiler  should  have  a corresponding  lower  development 
cost. 

The  principal  disadvantage  of  the  direct  code  method  is  that  the 
resulting  compiler  is  much  harder  to  retarget.  Consequently,  if  several 

* It  is  technically  feasible  to  implement  the  machine  independent  part  as 
a table  driven  interpreter,  which  behaves  as  a finite  state  machine.  How- 
ever, the  study  found  no  examples  of  such  an  architecture  in  actual  use. 
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equivalent  compilers  are  desired  for  different  target  machines,  then  the  total 
development  cost  for  the  group  of  compilers  will  be  considerably  greater  for 
the  direct  code  method  as  compared  with  either  of  the  other  two  methods. 

4.  Macro  Organized  Code  Generators 

If  the  machine  dependent  parts  of  the  node  type  related  programs 
are  implemented  as  Macros,  then  each  distinct  occurrence  of  a set  up  para- 
meters step  followed  by  a call  to  the  Object  Code  Output  primitive,  as  presented 
in  Section  3,  is  •replaced  by  a specific  Macro  call.  Thus,  this  method  requires 
the  creation  of  (generally)  as  many  Macro  functions  as  there  are  distinct  invoca- 
tions of  the  Object  Code  Output  primitive  in  the  direct  code  form  of  the  code 
generator. 

As  far  as  the  performance  of  a compiler  using  s Macro  organized  code 
generator,  as  compared  with  a compiler  using  a Directly  Programmed  Code 
Generator,  there  should  be  virtually  no  difference,  since  the  resulting  object 
forms  of  the  compilers  should  be  (almost)  identical.  The  principal  disadvantage 
of  the  Macro  mtthod  is  that  the  compiler  implementor  has  to  code  in  a Macro 
language  to  define  the  expansions  of  the  Macros,  and  to  run  a Macro  Processor 
to  obtain  the  object  form  of  a compiler.  These  additional  requirements  can 
result  in  increased  debugging  time  and  increased  computer  costs  in  developing 
the  compiler. 

The  principal  advantage  is  simply  that  all  the  machine  dependent  parts 
of  the  compiler  are  isolated  into  a file  of  Macro  definitions.  This  can  greatly 
facilitate  retargeting  the  compiler. 

5.  Table  Driver.  Code  Generators 

In  a table  driven  code  generator,  the  machine  dependent  parts  of  a 
node  type  related  program  are  each  implemented  as  a call  to  a table  driven 
interpreter.  That  is,  for  each  sequence  of  set  up  parameters,  call  Object 
Code  Output  primitive  pairs,  as  presented  in  Section  3,  which  occurs  in  a 
distinct  flow  path  of  the  machine  dependent  part,  there  is  a single  call  to 
the  interpreter.  This  interpreter  uses  the  state  information  set  up  by  the 
machine  dependent  part  to  refernce  a fixed  table.  Th«-  entries  in  this  table 
will  be  the  required  data  to  generate  the  appropriate  sequence  of  output  lines. 
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In  principle,  there  might  be  some  space/time  trade-offs  in  the  per- 
formance of  a compiler  using  a table  driven  code  generator,  as  compared 
with  the  other  two  methods.  However,  in  practice,  this  choice  of  method 
should  not  result  in  a significant  variation  in  performance.  The  principal 
advantage  of  the  table  driven  code  generator  is  that  it  is  an  alternative 
method  for  isolating  the  machine  dependent  part  of  the  compiler  to  the  Macro 
method.  The  Macro  method  uses  a file  of  Macros  definitions  to  represent 
the  machine  dependent  requirements,  and  the  table  driven  method  uses  a 
table.  Consequently,  one  should  consider  only  the  comparison  of  the  table 
driven  and  Macro  methods.  For  table  driven  code  generators,  it  is  some- 
what more  difficult  to  plan  in  advance  the  form  of  Macro  calls  required  for 
a variety  of  target  computers  with  very  different  hardware  architectures. 
However,  in  comparing  the  advantages  and  disadvantages  of  these  two  methods, 
the  most  general  conclusion  would  likely  be  that  the  evaluation  depends  on 
the  point  of  view  of  the  implementor  --he  will  most  likely  prefer  the  method 
with  which  he  has  had  more  experience. 
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CHAPTER  8 

HOW  TO  COMPARE  COMPILERS  IN  THE  SAME  ENVIRONMENT 
Introduction 


In  this  chapter,  a detailed  discussion  is  presented  of  the  results 
of  our  investigation  A the  same  environment  question: 

How  can  two  compilers  with  the  same  features 
and  operating  in  die  same  environment  be 
compared  ? 

This  chapter  will  include: 

• A discussion  of  each  step  taken  in  the  investigation 
the  same  environment  question. 

• A discussion  of  desirable  related  work  beyond  the 
scope  of  the  present  study. 
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• A discussion  of  how  the  results  of  the  present  study, 
together  with  the  indicated  related  work  could  be  used 

to  assign  a dollar  value  to  the  differences  in  performance 
between  two  compilers  due  to  differences  in  die  compilers' 
architecture  and  algorithms. 

Steps  taken  in  this  study.  The  following  is  a list  of  the  steps 
taken  in  the  study  of  the  same  environment  question. 

• A list  of  language  elements  was  prepared  for  use  in 
generating  User  Profiles.  (See  Section  5.  ) 

• For  each  of  five  catego;  i ■m  of  language  elements, 
methods  were  established  for  generating  test  programs 
to  be  used  in  evaluating  compiler  performance  with 
respect  to  the  language  elements  in  the  category. 

These  methods  are  discussed  in  Chapter  9. 

Each  of  these  two  steps  will  be  discussed  in  further  detail  in  Section  2. 

Related  work.  The  "desirable  related  work"  to  be  discussed  in 
Section  3 consists  of: 

• Investigating  methods  for  collecting  data  to  be  used  for 
generating  static  and  dynamic  User  Profiles. 

• Investigating  methods  of  reducing  such  collected  data 
by  automatic  means  so  as  co  facilitate  the  generation 
of  static  and  dynamic  User  Profiles. 
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• Prepare  test  programs  by  the  methods  described  in 
Chapter  9 and  use  these  programs  to  generate  Compiler 
Performance  Profiles. 

• Use  User  Profiles  to  establish  "Gibson  mix"  for  uaers. 

Using  the  results.  In  Section  4,  a discussion  is  presented  of 
how  the  results  of  the  investigation  of  the  same  environment,  question 
can  be  used  to  assign  a dollar  value  various  aspects  of  using  a compiler. 


2.  Steps  of  the  Study  of  the  Same  Environment  Question 

For  each  of  the  two  steps  taken  in  the  study  of  the  same  environ- 
ment question,  a discussion  is  presented  below.  This  discussion 
includes  a description  of  the  objectives  for  the  step  and  the  techniques 
used  to  fulfill  the  objectives. 

Create  list  of  language  elements.  The  objectives  that  the  list 
was  intended  to  fulfill  are  listed  below: 

• To  be  as  complete  as  possible  (within  the  budgetary 
constraints  of  the  project). 

• To  avoid  an  organization  that  will  result  in  one  element 
representing  a very  large  fraction  of  language  forms  in 
users'  programs. 

• To  have  the  list  represent  language  elements  which  are 
not  only  useful  for  describing  the  manner  in  which  high 
level  language  is  used,  but  also  those  about  which 
statistics  comprising  a User  Profile  can  be  collected  by 
some  relatively  simple  means,  for  example,  instrumenting 
a compiler. 
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The  techniques  used  to  generate  a list  of  language  elements 
fulfilling  the  above  objectives  are  listed  below. 

• Review  papers  and  reports  which  discuss  the  relative 
frequency  of  occurrences  of  high  level  language 
syntactic  forms. 

• Organize  the  list  into  a number  of  convenient  categories 
and  sub-categories,  so  that  very  rarely  occurring  cases 
can  be  grouped  together  statistically. 

• Break  down  highly  used  syntactic  forms  into  a number  of 
separate  cases  in  order  to  have  a more  detailed 

characterization  of  a User  Profile.  Hopefully,  the  level 

of  detail  should  be  such  that  no  single  language  element 
(syntactic  form)  should  represent  more  than  approximately 
ten  percent  of  the  total  cases. 
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Generating  methods  for  preparing  test  programs.  The  objects 
to  be  satisfied  by  the  methods  for  preparing  test  programs  are  listed 
below. 

* 

• Isolate  the  effect  of  the  language  element  for  which  the  i 

test  programs  are  generated.  * j 

e Keep  the  number  of  test  programs  required  to  measure  J 

performance  with  respect  to  a single  language  to  as  . i 

few  as  possible.  j 

• Keep  each  test  program  as  simple  structurally  as  j 

possible.  The  generation  of  test  programs  could  ! 

possibly  become  automated  provided  they  are  kept 

structurally  simple.  I 

• The  methods  should  be  easy  to  understand  and  to  put  | 

into  practice.  i 

• The  procedure  to  calculate  a performance  measure  for  j 

the  language  element  in  terms  of  data  collected  from  i 

compiling  and  executing  the  test  programs  should  be  j 

simple  and  straightforward.  - 

i 

The  techniques  used  in  developing  the  desired  methods  for  . 

generating  test  programs  are  listed  below.  These  techniques  are 
discussed  in  more  detail  in  Chapter  9. 

• Define  a test  program  which  can  b-i  used  to  measure  a 
reference  or  base  value  for  the  language  element. 

This  base  program  will  not  use  the  language  element 
under  consideration.  Then  establish  a measurement 
for  1 (or  n,‘  occurrences  of  the  language  element. 

The  desired  performance  measurement  is  found  by 
taking  the  difference  (divided  oy  n)  of  the  measured 
performance  between  the  second  and  base  test 

programs.  ! 

• Establish  a sequence  of  test  programs  containing  nj,  ! 

ng,  , . . , nm  c 'currences  of  the  language  feature 

under  consideration.  The  measured  performance 
values  for  each  test  program  are  plotted  as  functions 
of  n^.  The  slopes  calculated  for  the  least  mean 
square  line  fitting  the  test  data  will  be  used  as  the 
calculated  performance  values  for  the  language 
feature. 

• Same  as  the  preceding,  except  that  the  intercept  for  n = 0 

is  calculated.  This  is  compared  with  the  base  performance 
vr.lue  as  determined  above.  If  very  different,  this 
indicates  gross  non-linearity  of  performance  with 
number  of  occurrences  of  the  language  element. 
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3.  Desireable  Related  Work 

There  are  a number  of  important  problems  related  to  the  evaluation 
of  compiler  performance  that  are  beyond  the  scope  of  the  present  study. 
Several  such  problems  are  discussed  below. 

Collecting  data  for  User  Profiles.  There  are  several  obvious 
methods  which  might  be  useful  for  collecting  the  data  in  terms  of  which 
a User  Profile  may  be  generated.  Listed  below  are  several  methods 
that  are  worthwhile  to  investigate  concerning  the  possibility  that  User 
Profile  data  can  be  collected  cheaply  by  automatic  methods. 

Examples  of  methods  which  might  be  investigated  for  collecting 
static  User  Profile  data  are  the  following: 

• Build  instruments  into  selected  modules  of  a compiler 
which  caui  count  the  occurrences  of  syntactic  forms 
processed  by  the  module. 

• For  modules  which  are  used  for  a single  syntactic  form, 
a trace  mechanism  could  count  the  occurrences  of  calls 
to  this  module. 

• Build  simple  finite  state  machine  procedures  to  count 
the  occurrences  of  specific  iauiguage  elements. 

Examples  of  methods  which  might  be  investigated  for  collecting 
dynamic  User  Profile  data  are  the  following: 

• Build  into  the  code  generator  of  a compiler  the  changes 
required  so  that  each  statement  (or  branch  of  a conditional) 
when  executed  causes  a counter  to  be  incremented.  Also 
build  instruments  to  collect  static  data  statement  by 
statement.  The  counts  derived  during  execution  can  be 
used  as  weights  to  combine  with  statement  level  static 
data  to  produce  a dynamic  User  Profile. 

• Build  into  the  compiler  changes  required  to  count  each 
execution  of  a block  of  code.  Also  build  instruments 
to  collect  static  profile  data  for  each  such  block.  The 
counts  and  block  profiie  data  can  be  combined  as  above. 

One  further  aspect  of  the  language  elements  for  User  Profiles 
deserves  special  attention.  It  is  obvious  that  executable  statements 
nested  within  FOR  loops  will  contribute  by  some  multiplicity  to  the 
time  of  execution  of  the  object  code  generated  by  the  compiler.  However, 
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such  a statement  still  should  contribute  (approximately)  the  same  as  a 
similar  statement  not  in  any  FOR  L^op  to  the  compilation  time  of  a 
program.  If  one  is  only  interested  in  compiler  execution  performance, 
then  no  effort  is  required  tc  calculate  or  estimate  an  appropriate  object 
code  execution  multiplicity  factor  for  statements  within  FOR  loop*.  If 
object  code  execution  performance  is  of  interest  then  it  is  necessary  to 
make  such  a calculation  or  estimate. 

The  only  way  a completely  accurate  multiplicity  factor  can  be 
determined  is  by  collecting  dynamically  execution  counts  for  contiguous 
sequences  of  executable  code  as  suggested  above.  It  is  easy  to  see  that 
the  results  of  such  an  instrumentation  method  would  readily  permit  a 
highly  accurate  dynamic  User  Profile  to  be  established. 

Failing  the  availability  of  the  above  instrumentation  in  a compiler, 
the  lict  of  language  elements  for  User  Profiles  presen  ;ed  in  Section  5 
include  the  following: 

« A histogram  of  the  number  of  occurrences  of  nested 
FOR  loops  of  depth  N. 

• Histograms  of  the  number  of  executable  source 
language  forms  nested  N levels  deep  within  FOR 
loops. 

At  the  present  time  no  specific  recommendation  is  made  of  how  these  static 
data  should  be  used  to  estimate  the  desired  multiplicity  factors.  However, 
as  experience  accumulates  in  collecting  these  data  for  actual  static  User 
Profiles,  methods  for  estimating  the  multiplicity  factors  should  s lggest 
themselves. 

Automatic  generation  of  User  Profiles.  U the  raw  User  Profile 
can  be  collected  automatically  by  one  or  more  of  the  above  methods, 
the  data  could  be  stored  in  one  or  more  files  in  a form  suitable  for  later 
processing.  Then,  the  raw  data  as  contained  in  the  file  could  be 
subsequently  processed  to  calculate  for  each  language  element  the 
following: 

• The  average  number  of  static  occurrences  of  the  element 
in  a program  comprising  the  user's  environment. 
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• The  average  number  of  executions  of  the  language  element 
in  the  user's  environment.  (This  average  should  take 
into  account  the  relative  frequency  with  which  different 
programs  or  blocks  are.  executed. ) 


jf  Generate  actual  Compiler  Performance  Profiles.  Up  to  this 

| point,  all  the  preceding  discussion  indicated  how  User  Profiles  might 

be  generated  for  the  language  elements  listed  in  Section  5.  These 
f-  suggestions  are  based  solely  on  theoretical  considerations.  In  order  to 

determine  the  usefulness  of  the  methods  described  in  this  chapter, 

■ actual  Compiler  Performance  Profiles  should  be  generated  by  the 

\ methods  described  in  Chapter  9.  Only  from  the  accumulation  of 

• experience  with  actual  Compiler  Performance  Profiles,  can  valuable 

l insights  be  gained  as  to  what  changes  are  desirable  in  the  language 

i 

f elements  used  for  defining  both  User  Profiles  and  Compiler  Profiles, 

t and  ultimately,  the  performance  values  that  are  appropriate  to  assign 

| | to  a particular  compiler  in  a particular  user  application  environment. 


Other  uses  of  a User  Profile.  Besides  combining  User  and 
Compiler  Performance  Profiles,  a User  Profile  might  have  other  uses. 

One  such  other  use  that  might  be  worth  investigating  is  the  possibility 
of  using  a User  Profile  as  the  basi3  for  establishing  a "Gibson  mix" 
definition  of  the  user's  applications  environment.  This  "user  Gibson  mix" 
would  be  used  to  evaluate  the  relative  speed  and  size  characteristics 
of  different  computers  and  operating  systems  for  supporting  the  user's 
application  programs  to  be  executed. 

4 . Using  t he  Results  to  Calculate  Dollar  Valuations  of  Compilers 

in  the  Same  Environment 

Introduction.  It  is  assumed  for  the  purposes  of  this  section 
that  one  has  compiled  a User  Profile  by  the  methods  discussed  in  this 
chapter,  and  that  one  has  also  written,  complied,  and  executed  test 
programs  by  the  methods  described  in  Chapter  9 to  obtain  c Compiler 
Performance  Profile.  These  results  are  then  used  as  follcv/s: 

• Combine  the  User  Profile  and  Compiler  Performance 
Profile  to  obtain  four  figure  of  merit  evaluations 
related  to  a "typical"  user  program.  These  evaluations 
constitute  the  Compiler  Evaluation  Profile. 
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• Combine  these  figures  of  merit  with  addition?! 
administrative  data  to  calculate  useful  dollar 
valuations  of  the  compiler. 

The  method  to  be  used  to  combine  the  User  Profile  and  Compiler 
Performance  Profile  is  described  below,  together  with  an  interpretation 
of  the  four  resulting  figures  of  merit.  Finally,  the  calculation  of  dollar 
valuations  is  discussed. 

Combining  profiles.  Ultimately,  the  combination  of  the  User 
Profile  and  Compiler  Performance  Profile  should  give  a figure  of 
merit  for  each  of  four  criteria  for  a "typical"  user  program.  The  four 
criteria  are: 

• Time  to  compile. 

• Partition  space  required. 

• Time  to  execute. 

• Size  of  executable  program. 

The  time  to  compile  a "typical"  user  program  is  calculated  in  a 
simple,  straightforward  manner.  For  those  elements  whose  time  to 
compile  performance  data  indicate  a linear  performance  curve,  simply 
multiply  the  Compiler  Performance  Frofile  time  to  compile  coefficient 
by  the  number  of  occurrences  indicated  in  the  corresponding  static  User 
Profile  element.  For  non-linear  performance  cases,  the  characterization 
of  the  non-linear  curve  is  combined  with  the  number  of  occurrences 
indicated.  The  grand  total  for  all  the  language  elements  is  the  desired 
time  to  compile  a "typical"  user  program. 

The  partition  space  required  to  compile  a "typical"  user  program 
could  be  calculated  in  the  same  manner  as  above.  However,  it  is  likely 
that  the  average  or  typical  space  requirement  is  not  as  useful  as,  say, 
the  ninetieth,  ninety -fifth,  and  ninety-ninth  percentile  data.  These  later 
figures  would  indicate  the  space  required  to  compile  90%,  95%,  99%, 
etc.  of  the  user's  programs.  By  means  of  these  figures  and  knowledge 
of  the  actual  quantity  of  space  available,  one  could  interpolate  to 
determine  approximately  tlie  fraction  of  user  programs  thet  could  be 
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compiled  in  the  available  space.  Presumably,  the  remaining  fraction,  of 
programs  would  have  to  be  reprogrammed  into  smaller  programs  in 
order  for  them  to  be  compiled.  The  manner  in  which  these  percentile 
figures  might  be  determined  is  another  problem  involving  User  Profiles 
that  might  be  profitably  investigated  in  a separate  study. 

The  time  to  execute  a "typical"  user  program  would  be  determined 
in  the  same  manner  as  the  time  to  compile,  except  the  dynamic  User 
Profile  data  would  be  used  instead  of  the  static  User  Profile. 


The  size  of  executable  program  for  the  "typical"  user  program 
would  also  be  determined  from  the  dynamic  User  Profile  combined  with 
the  Compiler  Performance  Profile,  except  that  for  each  language  element 
the  "size  oi  object  program  as  assembled"  data  would  be  used  in  the 
Compiler  Performance  Profile. 

Dollar  Valuations.  If  we  assume  that  the  User  Profile  and 
Compiler  Performance  Profile  data  have  been  combiner , then  the 
results  would  include  four  figures  of  merit  as  follows: 

• Time  to  compile  a "typical"  user  prograi..  , 

• Either: 

• Partition  space  required  to  compile  a 
"typical"  user  program, 

Or: 

• Fraction  of  user  programs  that  cannot 
be  compiled  in  the  avail-: ble  space. 

• Time  to  execute  a "typical”  user  program. 

• Size  of  "typical"  user  program. 

Now  assume  that  the  following  additional  administrative  data  is  also 
available: 


4 


Number  of  compilations  expected  annually  (or  for  life  of 
computer  /compile  r). 

Number  of  program  executions  expected  annually  (or  for 
life  of  computer /compiler). 
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Cost  of  unit  of  partition  space. 
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• Cost  of  reprogramming  a typical  large  user  program. 

• Operating  system  overhead. 


The  following  dollar  figures  could  then  be  calculated: 

• Annual  (or  lifetime)  dollar  costs  for  compiling  user  programs. 

• Annual  (or  lifetime)  dollar  costs  fo'.'  executing  user  programs. 

• Expected  cost  (if  any)  for  reprogramming  existing  user 
programs  so  that  they  can  be  compiled  in  the  available 
space. 

These  dollar  figures  can  be  used  in  conjunction  with  procurement  cost 
of  the  compilers  under  consideration  to  achieve  the  best  cost/benefit 
result. 


5.  A List  of  Language  Elements  to  be  Used  for  Generating  a User 

Profile 

Introduction.  This  section  presents  a list  of  source  language 
elements  with  respect  to  which  a compiler's  performance  can  be 
measured.  Included  are  features  which  are  relevant  to  many  program- 
ming languages,  but  most  importantly  the  A2D  language  (since  AED  is 
representative  of  a good  systems  development  language)  and  also  to  the 
JOVLAL/J3B  language  (since  J3B  is  a representative  of  a user  oriented 
language). 

The  list  is  organized  into  the  following  five  categories: 

• Lexical  elements . 

• Declarative  elements. 

• Scope  definition  elements . 

• Program  control  elements  . 

• Data  manipulation  and  compulational  elements. 

For  each  of  these  categories,  an  outline  organized  sub-section  of  language 
elements  is  presented.  The  listed  elements  are  described  in  terms  of 
the  statistic  that  would  be  collected  to  represent  this  element  in  a User 
Profile.  For  each  element,  Chapter  9 presents  a description  of  how  test 
programs  could  be  prepared  to  test  compiler  and  object  code  performance 
with  respect  to  the  element.  In  combination,  the  results  of  accumulating 
data  from  these  test  compilation  and  object  code  executions  comprise  a 
Compiler  Performance  Profile. 
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Lexical  elements. 


Features  involving  lines,  statements,  characters  applicable 
to  comments,  declarative,  and  executable  text.  (Features 
to  be  measured  for  each  of  comments,  declaratives,  and 
executable  text  separately.) 

1.  Number  of  Source  Lines. 

2.  Number  of  Source  Statements. 

3.  Number  of  Blank  Lines. 

4.  Number  of  Blank  Characters. 

5.  Number  of  Non-blank  Characters. 

6.  Number  of  Blank  Sequences  of  Length  n (Histogram). 

Token  features  applicable  to  declarative  and  executable  text. 
(Measures  to  be  made  for  declarative  and  executable  text 
separately. ) 

1.  Punctuation  (number  of  references  to  each). 

2.  Keywords  (number  of  references  to  each). 

3.  User  declared  tokens  of  Length  n (Histogram  of  number, 
of  references  to  token  of  length  n). 

Number  of  .INSERT  (AED)/COMPOOL  (J3B)  Statements.  (Note: 
These  statements  cause  the  compiler  to  editorially  insert  possibly 
large  files  into  the  compiler  input  stream.  What  is  desired  is 
to  measure  the  compilers  performance  in  making  this  insertion 
as  a function  of  file  size.) 


II.  Declarative  elements.  (Note:  A through  D constitute  independent 
dimensions  of  element  classes.  That  is,  each  element  has  an  attribute  in 
each  category  A through  D.  However,  not  all  combinations  in  the 
Cartesian  produce  space  of  AxBxCxD  are  meaningful.  Category  E are 
special  declarative  elements  that  do  not  have  all  the  attributes  of  A 
through  D.  Statics  are  to  be  collected  for  both  the  number  of  declarations 
of  each  meaningful  combination,  and  the  number  of  references  to  a 
variable  with  such  a declaration.  ) 
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A.  Scope  and  Storage  Class. 

1.  Static  internal. 

a.  Number  declared  at  Scoping  level  n (Histogram). 

b.  Number  i»t  level  n replacing  previously  declaration 
for  token  at  lower  (numerical)  level. 

2.  Static  external. 

3.  Automatic  (internal). 

a.  Number  declared  at  Seeping  level  n (Histogram). 

b.  Number  at  level  £ replacing  previously  declaration 
for  token  at  lower  (numerical)  level. 

4.  "Based"  (Beads  and  Bead  Components  in  AED  only). 

5.  Parameters. 

a.  By-vaiue  type*. 

b.  By-reference  type. 

B.  Structure  Type. 


1.  Scalar  (That  is:  a simple  variable). 

2.  Array. 

a.  1-dimensional  (AED  and  J3B). 

b.  2 -dimensional  (J3B  only). 

3.  Table  (J3B  only)  (Histogram  over  number  of  items  in 
Table)  (Note:  Items  within  the  table  have  data  types; 
the  table  itself  does  not.  ) 

4.  Table  Item  (J3B  only). 

a.  Bit. 

b.  Byte. 

c.  Half  word. 

d.  Full  word. 

e.  Other. 

5.  Bead  (AED  only)  (Histogram  over  number  of  components 
in  Bead)  (Note:  Components  within  a Bead  have  data 
types;  the  Bead  itself  does  not.  ) 

6.  Bead  Component  (AED  only). 

a.  Bit. 

b.  Byte. 

c.  Half  word. 

d.  Full  word. 

c.  Other. 

♦Note:  Current  versions  of  AED  and  J3B  do  not  have  by-value  type 
parameters.  However,  they  are  panned  for  future  versions. 
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C.  Data  Type . 

1.  Integer  of  length  n (Histogram).  (In  AED  also  used 
for  Bit  operations.  ) 

2.  Real. 

3.  Character  String  of  length  n (Histogram  in  J3B 
only  --in  AED  character  string  variables  are 
always  variable  length. ) 

4.  Bit  String  of  length  n (Histogram).  (J3B  only) 

5.  Boolean.  (AED  only) 

6.  Pointer. (AED  only ) 

7.  Label. (Parameter  in  AED  only  or  in  AED  and  J3B 
as  a component  of  a switch  declaration  which  is, 

in  effect,  an  Array  of  Label  variables.  For  switch 
declarations,  a histogram  should  be  collected  of 
the  number  of  switches  having  n labels.  ) 

8.  Procedure. (Parameter  in  AED  only) 

D.  Initial  Values. 

(Note:  What  is  desired  here  is  to  determine  the  compiler 
performance  (and  the  performance  of  the  executable  code) 
when  declaring  (and  referencing)  variables  with  initial  values. 
For  each  data  type,  certain  initial  values  are  of  particular 
interest  since  they  are  likely  to  occur  with  high  frequency, 
and  a compiler  might  be  designed  to  handle  these  values  with 
greater  efficiency.) 

1.  Integer. 

a.  0 (Zero).  (Note:  Default  initialization) 

b.  1. 

c.  Other. 

2.  Real. 

a.  0 (Zero).  (Note:  Default  initialization) 

b.  1. 

c.  Other. 
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3.  Character  String. 

a.  Blanks.  (Note:  Default  initialization) 

b.  Other. 

4.  Bit  String. 

a.  0's.  (Note:  Default  initialization) 

b.  Other. 

5.  Boolean.  (AED  only) 

a.  FALSE.  (Note:  Default  initialization) 

b.  TRUE. 

6.  Pointer. 

a.  NULL.  (Note:  Default  initialization) 

b.  Other. 

E.  Procedures  and  Functions. 

(Note:  In  AED,  internal  procedures  are  not  required  to  be 
declared.  In  J3B,  an  internal  procedure  must  be  declared 
before  it  is  CALLED.  Function  declarations  are  "valued- 
procedures  and  have  a data  type  (See  C above).  It  is 
desired  to  measure  the  compilers  performance  for  each 
type  of  procedure /function  declaration.  Histograms  for 
each  type  are  to  be  collected  over  the  number  of  parameters 
of  type  by-value*  or  by-reference. ) 

1.  Number  of  internal  procedures  with  n parameters. 

2.  Number  of  internal  procedures  with  n by-value 

parameters. 

3.  Number  of  internal  procedures  vtith  n by-reference 
parameters. 

4.  Number  of  external  procedures  with  n parameters. 

5.  Number  of  external  procedures  with  n by-value 

parameters. 

6.  Number  of  external  procedures  with  n_  by-reference 
parameters. 


* See  previous  footnote  for  by -value  parameters. 
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7.  Number  of  internal  functions  with  n parameters. 

8.  Number  cf  internal  f>onctions  with  n by -value  parameters. 

9.  Number  of  internal  functions  with  n by-reference 
parameters. 

10.  Number  of  external  functions  with  n parameters. 

11.  Number  of  external  functions  with  n by-value  parameters. 

12.  Number  of  external  functions  with  n by-reference 
parameters. 

Scope  definition  elements. 

. Number  of  DEFINE  PROCEDURE. . . END  statement  pairs. 

B.  Number  of  BEGIN. . . END  statement  pairs.  (Note:  BEGIN 
is  a scoping  boundary  in  AED  but  not  in  J3B.  ) 

C.  riNI  (AED)/TERM  (J3B)  --  single  statement  acting  as 
logical  end -of -file. 

D.  Maximum  number  of  declaration  levels  (Note:  Maximum  at 
most  2 in  J3B). 

E.  Histograms  for  n-th  level  of  scoping*  (The  zero-th  level  is 
outside  any  procedure  or  BEGIN-END  block  - For  each 
procedure  or  BEGIN-END  block  the  level  is  Incremented. 

by  1. ) 

1.  Number  of  declaration  statements  at  level  n. 

2.  Number  of  executable  statements  at  level  n. 

3.  Number  of  user  tokens  declared  at  level  n. 

4.  Number  of  user  tokens  declared  at  level  ri  which 
are  already  declared  at  a lower  (numerically)  level. 

5.  Number  of  BEGIN-END  blocks  initiating  a new  block 
at  a level  n_  (AED  only). 

6.  Number  of  Procedure  Definitions  initiating  a new 
block  at  level  n. 

7.  Number  of  labels  defined  at  level  n. 


*rhese  histograms  only  meaningful  for  AED  since  J3B  does  not 
permit  more  than  levels  0 and  1. 
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IV. 


Program  control  elements. 
A.  IF  Constructions. 


(Form  of  IF  is: 

IF  X THEN  SI  [ELSE  S2] 

X represents  a Boolean  (AED)  or  Bit  (J3B)  variable  or  expression. 
Thus,  X_  may  be  a variable,  a primitive  expression,  or  a com- 
pound expression.  It  is  desired  to  determine  the  distribution  of 
X forms  among  these  three  categories.  The  various  detailed 
forms  ofl£are  outlined  in  Section  V under ’Boolean  Expressions. 

SI  and  S2  represent  statements.  It  is  desired  to  consider  the 
configuration  of  particular  statement  forms  for  SI  and  S2 
separately. ) 


1. 


General  Form  of  X.  • 

a.  Boolean  (AED)  or  Bit  (J3B)  variable. 


b. 


Simple  Predicate  Form. 

(A  predicate  B.  Predicates  are  >,  <,  > = , < = ) 


c.  Compound  Boolean  Expression. 
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2.  Forms  of  SI. 

a.  BEGIN. 

b.  CALL. 

c.  FOR. 

d.  IF. 

e.  GOTO. 

f.  Assignment. 

j.  Forms  of  S2. 

a.  BEGIN. 

b.  CALL. 

c.  FOR. 

d.  IF. 

e.  GOTO. 

f.  Assignment. 

B.  FOR  Constructions. 

I.  General  Forms  of  FOR  Statements. 

al.  FOR  I=E  Step  F UNTIL  G DO  S (AED) 

a2.  FOR  I (E  BY  F WHILE  X);  S (J3B) 

(Note:  a2  more  general  than  al.  If  X has  the  form 
I-»=G,  then  these  forms  are  equivalent.) 

bl.  FOR  I=E  WHILE  X DO  S (AED) 

b2.  FOR  I (E  WHILE  X);  S ( J3B) 

c.  FORUEj,  E En  DO  S (AED) 

d.  FOR  Isl/Qj/,  /Qz/,  . . . , /Qn/ DOS  (AED) 
where: 

. n>l, 

. /Qi/  is  either  of  the  form  Ei  or  of  the 
form  Ei  STEP  Fi  until  Gi,  and 
. at  least  one  /Qi/  )s  not  of  the  form  Ei. 

el.  WHILE  X DO  S (AED) 

e2.  WHILE  X;S  (J3B) 

It  is  desired  to  determine  the  relative  occurrence  of  each 
form,  including  histograms  over  n for  forms  c and  d. 
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Forms  of  I. 

a.  Simple  Integer. 

(Note:  The  following  are  allowed  only  for  AED) 

b.  Subscripted  Integer  Array  Element. 

c.  Integer  Bead  Component. 

d.  Simple  Real  Variable. 

e.  Subscripted  Real  Array  Element. 

f.  Real  Bead  Component. 

g.  Simple  Pointer  Variable. 

h.  Subscripted  Pointer  Array  Element. 

i.  Pointer  Bead  Component. 

j.  Simple  Boolean  Variable. 

k.  Subscripted  Boolean  Array  Element. 

l.  Boolean  Bead  Component. 

General  Form  of  E (or  Ei),  F (or  Fi),  or  G (or  Gi). 

(Statistics  for  three  forms  to  be  collected  separately) 

-.  Single  literal,  or  non- subscripted  variable  with 
the  same  data  type  as  I.  (AED  or  J3B  - in  J3B 
must  be  integer  data  type.) 

b.  Other  (AED  or  J3B  - in  J3B  must  be  an  integer 
expression.) 

(Note:  Other  forms  are  treated  in  detail  as  arithmetic 
or  Boolean  expressions  in  Section  V.) 

Form  of  X, 

a.  Simple  Boolean  (AED)  or  Bit  (J3B)  variable. 

b.  Other. 

(Note:  The  non- simple  forms  of  X are  treated  in  detail 
as  Boolean  expressions  in  Section  V.) 

Form  of  S. 

a.  BEGIN. 

b.  CALL. 

c . FOR. 


GOTO. 

Assignment, 


Histogram  of  the  number  of  FOR  loops  nested  n level  deep. 
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C.  Other  (simple)  program  control  elements 


1 . Label  Definition, 

2.  GOTO. 

a.  Simple  label. 

b.  Switch. 

Data  manipulation  and  computational  elements. 


Environmental  Elements. 


Assignm*  r-t  Statement. 

E form  in  FOR  Statement. 

F form  in  FOR  Statement. 

G form  in  FOR  Statement. 

X form  in  FOR  Statement. 

X form  in  IF  Statement. 

Subscript. 

Argument  to  Procedure  or  Function  Call. 


Nesting  Histograms. 

1.  Number  of  simple  variable  or  literal  references  occurring 
at  a FOR  loop  nesting  depth  of  n. 

2.  Number  of  references  to  parameters  at  nesting  depth  of  n. 

3.  Number  of  references  to  external  data  at  nesting  depth  of  n. 

4.  Number  of  references  to  global  internal  data  at  nesting 
depth  of  ru 

5.  Number  of  references  to  local  static  data  at  reference 
depth  of  n. 

6 Number  of  references  to  local  automatic  data  at  reference 
depth  of  rt. 

7.  Number  of  reference  to  automatic  data  at  reference  depth 
of  £ which  is  declared  in  a containing  Begin  or  Procedure 
Definition  block  (AED  only). 

8.  Number  of  single  subscripted  array  references  at  nesting 
depth  of  n. 

9.  Number  of  double  subscripted  array  references  at  nesting 
depth  of  n.  (AED  only) 


10.  Number  of  Bead  component  (AED)  or  Table  Items  (J3B) 
references  at  nesting  depth  of  n. 

11.  Number  of  arithmetic  operations  at  nesting  depth  of  n. 

a.  + 

b. 

c.  * 

d.  / 

12.  Number  of  data  type  conversions  at  nesting  depth  of  n_. 

a.  To  integer. 

b.  To  real. 

c.  To  pointer. 

13.  Number  of  function  calls  at  nesting  depth  of  n. 

a.  Functions  with  no  arguments. 

b.  Functions  with  single  argument. 

c.  Functions  with  two  arguments. 

d.  Functions  with  more  than  two  arguments. 

14.  Number  of  procedure  calls  at  nesting  depth  of  n. 

a.  Procedures  with  no  arguments. 

b.  Procedures  with  single  argument. 

c.  Procedure  with  two  arguments. 

d.  Procedures  with  more  than  two  arguments. 

15.  Total  number  of  arguments  to  called  functions  or 
procedures  at  nesting  dept  of  n. 

16.  Number  af  assignment,  statements  at  nesting  depth  of  n. 
j7.  Number  oi  iF--TIiEN's  at,  nesting  depth  of  n. 

U.»  Number  of  ELSE's  at  nesting  depth  of  n. 

lb.  Number  of  GOTO's  at  nesting  depth  of  n 

a.  To  label. 

b.  To  switch. 

C.  Form  of  Left  Hand  Side  of  Assignment  Statement. 


(Note:  Details  of  expression  forms  used  as  subscripts  are 

t . . j t . ,i  __  „ 4.1 „ • „ \ 

ridUUieu  at  iumiCUL  ctvpi  cooiwuo«  ; 

1.  Simple  variable, 

2.  Single  subscripted  variable  with  literal  subscript. 
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3.  Single  subscripted  variable  with  variable  subscript. 

4.  Single  subscripted  variable  with  expression  subscript. 

(Note:  5-10  valid  in  AED  only. ) 

5.  Double  subscripted  variable  with  two  literal  subscripts. 

6.  Double  subscripted  variable  with  one  literal  and  one  variable 

subscript. 

7.  Double  subscripted  variable  with  two  variable  subscripts. 

8.  Double  subscripted  variable  with  one  literal  and  one 

expression  subscript. 

9.  Double  subscripted  variable  with  one  variable  and  one 
expression  subscript. 

10.  Double  subscripted  variable  with  two  expression  su  bscripts. 

11.  Bead  component  (AED)  or  Table  Item  (J3B). 

Forms  of  Arithmetic  Expression;., 

1.  Literal,  (Special  values  depending  on  Data  Type) 

a.  0 (integer,  real). 

b.  I (integer,  real). 

TRUE.  (Boolean  - AED  only) 

d.  FALSE;.  (Boolean  - AED  only) 

e.  NULL.  (Pointer) 

f.  0's.  (bit  string  - J3B  only) 

g.  Blanks  (character  string  - J3B  only  - this  case 
requires  length  of  Blank  string  liteia  to  ecual the 
length  of  i.HS  variable  in  assignment  tUieir.ent). 

h.  Other. 

2.  Variable  (including  subscripting,  parameter,  Bead  com- 
ponent, table  iteml. 

(Note:  character  of  variables  wit  cur  reference  and  data  type 
conversions  are  handled  in  detail  in  the  histograms  above  -- 
see  V.  B.  12) 


3.  Function  call. 

4.  Variable  OPERATOR  Literal. 

a.  A+l, 

b.  A-2. 

c.  A*2. 

d.  A/2. 

e.  A*  *2. 

f.  A OPERATOR  Other  Literal. 

5.  Literal  OPERATOR  A. 

a.  1+A. 

b.  1-A. 

c.  2*A. 

d.  1/A. 

e.  e*#A  (e  = 2.  71828.  . . ), 

£.  Other  Literal  OPERATOR  A. 

6.  Va.-iapLe  OPERATOR  Varaible. 

a.  At  B. 

b.  A-B. 

c.  A*B, 

d.  A/B, 

e.  A v-;B. 

7.  Other  expressions. 

a.  Number  of  t's. 

b.  Number  of  -'s. 

(Ignore  unitary  •! ) (Note  occurrences  of  unitary  minus 
separately  from  binary  operator). 

c.  Number  of  :::,s. 

d.  Number  of  /'s, 

e.  Number  of  **'s. 

f.  Number  of  Literals. 

g.  Number  of  Variables. 

h.  Number  of  function  calls 

i.  Number  of  occurrences  of  ABS  function. 
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j.  Number  of  occurrences  of  .RSt  (AED)  or 
SHIFTR(  ) (J33). 

k.  Number  of  occurrences  of  .LS.  (AED)  or 
SHIFTL(  ) (J3B). 

l.  Number  of  occurrences  of  .A.  (AED  only) 

m.  Number  of  occurrences  of  . V.  (AED  only) 

n.  Number  of  occurrences  of  .N.  (AED  only) 

8.  Histograms  of  expressions  with  more  than  1 operator. 

a.  Number  of  expressions  occurring  with  £ operands. 

b.  Number  of  expressions  occurring  with  n variables. 
Number  of  expressions  occurring  with  n literals. 


c. 

d. 


Number  of  expressions  occurring  with  n function 
calls. 
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e.  Number  of  expressions  occurring  with  ji  pairs  of 
parenthesis  (explicit  only). 

f.  Number  of  expressions  occurring  with  n pairs  of 
parenthesis  including  implicit  parenthesis  for 
precedence  changes.  (For  example:  a*b+c*d  has 
2 implicit  pairs  of  parenthesis:  (a*b)  + (c*d).) 

E.  Forms  of  Boolean  Expressions. 


(Note:  Boolean  Forms  not  involving  Boolean  OPERATORS 
are  considered  simple.  All  others  are  called  compound. ) 

1.  Literal. 

a.  TRUE. 

b.  FALSE. 

2.  Variable  (including  subscripting,  parameter,  bead 
component,  table  item). 

(Note:  Character  of  variables  within  reference  and 
data  type  conversions  are  handled  in  detail  in  the 
histograms  under  section  B above.) 


3.  Single  Predicate  Form. 

a.  variable  PREDICATE  Literal. 
(1)  Predicates« 


(a)  EQUAL. 

(b)  NOT  EQUAL. 

(c)  LESS  THAN. 

(d)  GREATER  THAN. 

(e)  LESS  THAN  OR  EQUAL. 

(f)  GREATER  THAN  OR  EQUAL. 


(2)  Literals,  (depending  on  Data  Type  of  Variable) 

(a)  0 (integer,  real). 

(b)  1 (integer,  real). 

(Note:  Literals  (c)  through  (g)  apply  onLy  to 
EQUAL  and  NOT  EQUAL. ) 

(c)  Blanks,  (character  string,  J3B  only) 

(d)  00...  0 B.  (bit  string,  J3B  only) 

(e)  NULL,  (pointer) 

(f)  TRUE.  (Boolean  (AED)  or  Bit  (J3B)) 

(g)  FALSE.  (Boolean  (AED)  or  Bit  (J3B)) 

(h)  Other  Integer  or  Real  Literals. 

(i)  Other  non-numeric  Literals  (EQUAL  and 
NOT  EQUAL  Only). 

b.  Variable  PREDICATE  Variable. 

(Predicates  as  a.(l)  above) 

(Note:  The  above  categories  1 through  3 are  all  simple  ex- 
pressions. The  categories  to  follow  (4  through  6 are  all 
compound  expressions.) 

4.  Use  of  Unary  Boolean  NOT. 

a.  Preceding  single  Boolean  Variable. 

b.  Preceding  simple  Predicate  Form. 

c.  Preceding  Variable  within  an  expression. 

d.  Preceding  simple  Predicate  Form  within  an  expression. 

e.  Preceding  an  expression. 

f.  Other. 
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Binary  Boolean  Operators. 

a.  AND. 

b.  OR. 

c.  EQUIVALENT.  (AED  Only) 

d.  IMPLIES.  (AED  Only) 

e.  EXCLUSIVE  OR. (J3B  Only) 

Use  of  Boolean  OPERATOR. 

a.  Variable  OPERATOR  TRUE. 

b.  Variable  OPERATOR  FALSE. 

c.  TRUE  OPERATOR  Variable. 

d.  FALSE  OPERATOR  Variable. 

e.  Variable  OPERATOR  Variable. 

f.  Simple  Predicate  OPERATOR  TRUE. 

g.  Simple  Predicate  OPERATOR  FALSE. 

h.  TRUE  OPERATOR  Simple  Predicate. 

i.  FALSE  OPERATOR  Simple  Predicate. 

j.  Variable  OPERATOR  Simple  Predicate. 

k.  Simple  Predicate  OPERA  TOR  Variable. 

l.  Simple  Predicate  OPERATOR  Simple  Predicate. 

m.  Compound  Expression  OPERATOR  TRUE. 

n.  Compound  Expression  OPERATOR  FALSE, 

o.  TRUE  OPERATOR  Compound  Expression. 

p.  FALSE  OPERATOR  Compound  Expression, 

q.  Compound  Expression  OPERATOR  Variable. 

r.  Variable  OPERATOR  Compound  Expression. 

s.  Compound  Expression  OPERATOR  Simple  Predicate. 

t.  Simple  Predicate  OPERATOR  Compound  Expression. 


u. 


Compound  Expression  OPERATOR  Compound 
Expression. 
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CHAPTER  9 

HOW  TO  WRITE  TEST  PROGRAMS  FOR  GENERATING  COMPILER 

PERFORMANCE  PROFILES 


1.  Overview 

This  chapter  first  describes  the  generalized  approach  to  constructing 
and  evaluating  tests.  In  particular,  the  concept  of  isolating  separable 
sub-costs  associated  with  the  cost  of  a statement  is  explained.  This  is 
the  major  goal  of  the  series  of  tests  presented  in  Sections  2-6. 

Five  separate  series  of  tests  designed  to  evaluate  elements 
which  could  be  processed  differently  by  two  compilers  are  outlined. 

These  include: 


• Lexical  elements, 
e Declarative  elements, 
e Scope  definitions, 
e Program  control  elements, 
e Data  manipulation  and  computational  elements. 

Separability  of  statement  sub-costs.  The  prime  objective  of 
constructing  test  programs  is  to  isolate  separate  statement  sub-costs. 
There  are  three  sub-costs  associated  with  the  cost  of  a statement 
containing  one  or  more  sub-expressions: 


(1)  The  cost  of  each  expression  compiled  and  executed  in 
isolation. 

(2)  The  cost  of  the  statement  form  itself  (invariant, 
regardless  of  the  form  of  expression  used). 

(3)  The  residual  interactive  cost  of  each  expression  as 
used  in  the  context  of  the  particular  type  of  statement 
form. 


A major  goal  of  the  test  series  is  to  determine  items  (1),  (2),  and  (3) 
separately  for  various  statement  forms.  However,  the  three  sub-costs 
are,  in  general,  not  separable.  In  most  cases,  the  total  cost  of  a state- 
ment form  is  determined  using  the  simplest  possible  expression  forms, 
and  as  many  as  possible  separable  expression  costs  (sub-cost  (1)) 
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determined  and  subtracted  from  the  total.  This  process  provides  a 
"base  cost",  which  is  then  used  for  comparison  purposes  with  other 
forms  of  expressions  used  with  the  statement  being  tested. 

For  example, 

IF  expression  1 THEN  expression  2 ; 

is  the  IF-statement  form  in  AED.  If  F(  ) (subroutine  call)  is  used  as 
expression  2,  then,  since  F(  ) is  compilable  and  executable  in  isolation, 
gub-cost  (1)  is  separable  by  subtracting  the  cost  of  the  subroutine  call 
from  the  cost  of  the  total  IF-statement.  However,  the  cost  of  the 
interaction  bitween  the  THEN  and  the  subroutine  call  (F(  ) as  used  in 
the  context  of  THEN)  cannot  be  determined  this  simply. 

Some  statements  can,  however,  be  made  about  sub-cost  (3), 
after  tests  have  been  run  on  several  different  types  of  statement  forms, 
each  using  the  same  set  of  sub-expressions.  Specifically,  the  difference 
between  the  cost  of  one  statement  form  using  the  same  set  of  expressions 
can  be  compared  to  the  comparable  cost  using  another  statement  form. 

If  this  difference  is  negligible  this  indicates  that  sub-cost  (3)  is 
negligible  for  all  statement  types  examined,  since  the  type  of  statement 
in  which  the  expression  was  embedded  had  no  apparent  effect  on  its  cost. 
For  example,  consider  the  statement  forms: 


m 


Set  1: 


IF  expression  THEN  (Call) 
IF  expression  THEN  (Assigi 
IF  expression  THEN  (Loop) 


Set  2: 

FOR  expression  WHILE  expression  DO  (Call)  (d) 

FOR  expression  WHILE  expression  DO  (Assign. ) (e) 

FOR  expression  WHILE  expression  DO  (Loop)  (f) 

If  the  total  cost  difference  between  items  (b)  and  (a)  (or  (c)  and  (a))  is  the 
same  as  the  cost  difference  between  items  (e)  and  (d)  (or  (f)  and  (d)), 
then  the  residual  interactive  cost  (sub-cost  (3))  is  negligible  for  calls 
and  assignment  expressions  (or  calls  and  loop  expressions)  as  used  in 
IF  and  FOR  statements. 


Approach  to  test  construction.  To  determine  the  actual  cost  of 
various  language  constructs,  each  test  series  in  the  total  set  begins  with 
a skeleton  program  which  represents  a simple  (minimal)  set  of  statements. 
This  is  intended  to  allow  as  many  overhead  costs  as  possible  to  be 
subtracted  from  the  observed  test  figures  before  plotting  and  analyzing 
them.  The  skeleton  program  contains  just  the  source  statements  not 
related  to  the  test  to  be  performed  (statements  necessary  to  make  the 
test  program  compilable  or  executable),  plus  all  sub-expressions  which 
are  compilable  in  isolation  (sub-cost  1).  The  skeleton  test  is  compiled 
(and  executed  where  necessary)  in  order  to  obtain  a base  cost  figure  to 
be  subtracted  from  the  results  of  the  various  test  runs. 

Succeeding  test  programs  add  or  modify  the  basic  setup,  and 
performance  figures  are  measured  against  the  base  values.  It  is 
anticipated  that  most  (if  not  all)  such  comparison  figures  will  be  an 
incremental  amount  larger  than  the  base  figures,  and  that  this  increment 
is  a measure  of  the  difference  between  the  test  program  and  the  base.  In 
some  instances,  the  test  data  values  may  be  smaller  than  the  base,  showing 
that  the  base  is  not  a true  minimal  case,  but  the  performance  measure- 
ment comparisons  are  still  valid  even  in  this  unusual  case. 

Each  set  of  tests  is  written  as  a series  of  programs  in  which  the 
feature  to  be  tested  is  repeated  many  times.  The  first  test  program  in 
the  set  repeats  the  feature  LOW  times,  the  next  program  adds  STEP 
repetition  to  the  previous  number,  and  so  on  until  HIGH  repetitions  are 
reached  in  the  final  program  in  the  test  series.  The  integer  val  es 
assigned  to  LOW,  STEP,  and  HIGH  depend  upon  the  software  and  hardware 
measurement  facilities  available  on  the  particular  computer  and  operating 
system  being  used  for  the  1 ests. 

Evaluating  test  series  results.  After  subtracting  the  base  value 
from  the  test  figures,  the  results  of  the  test  runs  are  plotted,  and  a 
slope  which  graphically  shows  the  cost  of  the  statement  of  interest  is 
determined.  The  slope  of  this  graph  represents  the  basic  cost  of 
the  feature,  and  the  shape  of  the  graph  shows  whether  or  not  a fixed 
cost  may  be  associated  with  each  occurrence  of  the  feature.  If  the 
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graph  is  linear,  the  cost  for  each  occurrence  of  the  form  being  tested 
is  a fixed  amount;  if  the  graph  is  non-linear,  the  cost  is  effected  by  the 
number  of  repetitions  which  preceded  it  in  the  source  program. 

In  the  present  study  we  have  made  the  working  hypothesis  that 
all  such  graphs  should  be  of  the  linear  type.  If  the  results  of  the  test 
series  are  seen  to  be  inconsistent  with  this  hypothesis,  then  further  study 
would  be  required  to  determine  the  reasons  underlying  the  failure  of 
our  hypothesis  of  linearity. 

Categories  of  efficiency.  There  are  four  basic  compiler  evaluation 
efficiency  measures  of  interest,  broken  down  into  two  classes: 

Class  1:  Compiler  Operation. 

Measure  1:  Computer  Time  Efficiency.  (Processor  Time) 

Measure  2:  Computer  Memory  Usage.  (Core,  Drums, 
Disks,  etc. ) 

Class  2:  Resulting  Object  Code. 

Measure  3:  Execution  Speed. 

Measure  4:  Execution  Memory  Usage. 

Li  Measure  4,  this  figure  includes  the  actual  object  code  size  as  well  as 
additional  space  required  for  library  support  called  in  as  a direct 
ret. v'r.  of  the  source  code  statements  used  (number  conversions,  sub- 
routine call  linkage  mechanisms,  etc. ). 

t 

These  four  measurements  can  be  taken  either  on  "typical  programs", 
which  use  a mix  of  statements  and  operations  vypical  of  the  application 
for  which  the  compiler  is  to  be  used,  or  on  individual  statement  and 
phrase  forms,  which  require  many  more  test  programs,  but  which  are 
independent  of  the  specific  application.  The  test  programs  discussed 
in  this  chapter  are  of  the  latter  form;  i.  e. , they  test  efficiency  of 
individual  statement,  forme  without  regard  for  the  relative  importance 
of  each  form  or  the  relevant  compiler  application.  While  most  of  the 
tests  specified  in  this  chapter  concern  primarily  Measures  1 and  3, 
the  method  oresented  is  also  directlv  aooli  cable  to  Measures  2 and  4, 
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2,  Lexical  Elements 

Introduction.  The  class  of  lexical  elements  tests  exercises  the 
lexical  and  table  look-up  functional  elements  of  the  compiler  as  well  as 
input  processing  support  in  the  CPU.  These  tests  are  designed  to 
measure  compile  time  efficiency  and  execution  time  efficiency  in  the 
following  areas: 

e Formatting  features  --  number  of  source  lines,  source 
statements,  blank  lines,  blank  and  non -blank  characters, 
lengths  of  blank  character  sequences. 

e Punctuation,  keywords,  and  tokens. 

e External  program  elements. 

Some  tests  are  designed  to  be  compiled  only;  others  both  compiled 
and  executed.  This  difference  is  discussed  with  each  set  of  tests.  Also, 
skeleton  programs  resulting  in  base  values  to  be  subtracted  from  the 
test  run  figures  are  discussed  with  each  set  of  tests. 

Wherever  appropriate,  the  tests  are  performed  separately  on 
three  different  types  of  statements: 

• Comments. 

• Non -executable  declaration  statements. 

• Executable  statements. 

These  three  distinctions  are  not  necessarily  those  known  to  actually 
represent  differences  in  performance  among  different,  compilers  (or 
different  implementations  of  the  same  compiler)  but,  rather,  are 
intended  to  provide  a complete  set  of  tests  for  lexical  elements.  The 
structure  of  the  tests  is  simple  enough  to  permit  them  to  be  generated 
by  a program,  if  desired. 


Basic  overhead  costs.  A base  or  skeleton  program  is  constructed, 
ani  run  to  determine  a "base  cost"  figure  to  be  subtracted  from  the 
results  of  the  various  test  runs.  This  program  contains  only  those 
source  statements  which  are  necessary  to  make  the  program  compilable 
(or  executable,  where  noted)  and  which  are  not  related  to  the  test  to 
be  performed.  The  particular  lexical  elements  tests  consist  of  a series 


of  programs  repeating  the  statement  form  to  be  tested.  The  statement  is 
repeated  LOW  times,  and  the  number  of  repetitions  is  increased  by 
STEP  until  HIGH  number  of  statements  is  processed. 

The  skeleton  program  for  the  tests  which  are  compiled  only  in 
AED,  takes  the  form: 

BEGIN 

INTEGER  DUMMY  ; 

EXTERNAL  DUMMY  ; 

END  FINI 

The  dashed  lines  indicate  the  position  where  the  additional  test  program 
statements  are  to  be  added. 

Formatting  features.  This  set  of  tests  is  designed  to  measure 
the  overhead  costs  of  formatting  features: 

• Number  of  source  lines. 

• Number  of  source  statements. 

• Number  of  blank  lines. 

• Number  of  blank  and  non-blank  characters. 

• Lengths  of  blank  character  sequences. 

Each  formacting  feature  is  tested  on  comments,  declaration  statements, 
and  executable  statements.  Some  of  these  tests  serve  as  skeleton  tests 
for  other  features  and  are  discussed  where  applicable. 

Number  of  source  lines.  To  evaluate  the  compiler's  performance 
with  a varying  number  of  souirce  lines,  construct  three  separate  sets  of 
tests  to  process: 

• Comments. 

• Declaration  statements. 

• Executable  statements. 


First,  examine  the  effect  of  a varying  number  of  source  lines  in 
a comment.  Construct  a non-null  comment  and  add  it  to  the  skeleton 
program.  In  AED  comments  take  two  forms: 


1.  COMMENT  xxxj 

2.  ...  xxxxxxx  // 


The  first  of  these  two  forms  is  referred  to  as  a comment,  the  second  as 
a remark.  They  represent  however,  equivalent  ways  to  express  the 
character  string  xxxxxxx  as  a piece  of  non -processing,  descriptive  text 
within  an  AED  program. 

After  compiling  the  test  program  first  with  a one -line  comment 
and  then  with  a one-line  remark  and  recording  the  processing  time, 
then  increase  the  length  of  each  so  that  it  extends  over  more  than  one 
line.  Repeat  this  process  until  the  desired  number  of  tests  has  been 
compiled  (by  STEP  until  HIGH  number  is  reached).  After  subtracting 
off  the  time  required  to  compile  the  skeleton  program,  the  results  of 
these  test  runs  can  be  plotted  and  analyzed. 

Next,  construct  a representative  set  of  declaration  statements 
which  are  formatted  one  statement  per  source  line,  and  add  the  set  to 
the  skeleton  program.  In  AED,  this  could  take  the  form: 

INTEGER  A ; 

POINTER  ARRAY  B ; 

BOOLEAN  C ; 

Again,  compile  the  test  program  with  the  set  of  declaration  statements, 
and  record  the  processing  time.  Add  replications  of  the  same  set, 
recompile,  and  record  the  processing  time  (by  STEP  until  HIGH  number 
is  reached).  After  subtracting  off  the  time  required  to  compile  the 
skeleton  program,  the  results  of  these  test  runs  can  be  plotted  and 
analyzed. 

Lastly,  to  evaluate  the  compiler's  performance  with  respect  to 
fjiA  number  of  source  linos 9 construct  e r opresentutive  set  of  sxscutsbls 
statements  which  are  formatted  one  statement  per  source  line,  and  add 
it  to  the  skeleton  program.  Include  a declaration  of  each  different 
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variable  contained  in  an  executable  statement.  Perform  the  same 
repetitive  process  as  just  described  and,  again,  plot  the  results.  Note 
that  even  though  the  set  of  executable  statements  is  repeated,  the 
declaration  statements  need  appoar  only  once  in  the  test  program. 

Number  of  source  statements.  To  evaluate  the  compiler's 
performance  with  a varying  number  of  source  statements,  construct 
three  separate  sets  of  tests  to  process: 

e Comments. 

e Declaration  statements. 

e Executable  statements. 

The  tests  for  this  series  are  designed  so  as  to  make  the  effects  due  to 
the  number  of  lines  as  close  as  possible  to  those  measured  in  the  previous 
set,  so  that  they  may  be  factored  out  from  the  observed  compilation 
times. 

First,  to  examine  the  effects  of  a varying  the  number  of  comment 
source  statements,  construct  a single  source  line  which  consists  of  as 
many  comments  (AED  comments,  remarks,  or  both)  as  will  fit  on  the 
one  line.  Add  the  line  to  the  skeleton  program,  compile  it,  and  record 
the  processing  time.  Again,  repeat  the  process  by  increasing  the 
number  of  replications  of  the  commented  line,  and  record  the  results. 
Alternatively,  start  with  the  largest  "single  comment"  as  used  for  the 
first  set  of  source  line  tests.  Gradually  break  it  into  successively 
smaller  comments  until  each  is  packed  at  its  maximum  density.  Again, 
record  the  results. 

Next,  examine  the  effects  of  a varying  number  of  declaration 
source  statements.  Construct  a representative  set  of  declaration 
statements  packed  together  as  closely  as  possible.  This  may  include 
several  different  declaration  statements  per  line  as,  for  example: 

INTEGER  Al,  A2,  A3  ; POINTER  B1.B2,  B3  ; INTEGER  ARRAY 
C 1,  C2,  C3  ; 

BOOLEAN  D1,D2,D3,D4  ; REAL  El,  E2,E3,E4  ; 
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Add  the  set  to  the  skeleton  program,  compile  it,  and  record  the  processing 
time.  Again,  repeat  the  process  by  increasing  the  number  of  replications 
of  the  set  of  declarations  and  record  the  results. 

Lastly,  examining  the  effects  of  a varying  the  number  of  executable 
statements.  Replace  the  set  of  tested  -satures  in  the  previous  test  series 
with  a representative  set  of  executable  statements  packed  together  as 
closely  as  possible.  Perform  the  same  repetitive  testing  process.  Note 
that  even  though  the  set  of  executable  statements  is  repeated,  the 
declaration  statements  need  appear  only  once  in  the  test  program 

Number  of  blank  lines.  To  evaluate  the  compiler's  performance 
with  a varying  number  of  blank  lines,  construct  four  separate  sets  of 
tests  to  process  blank  lines  occurring: 

• Between  statements. 

• In  comments. 

• In  declaration  statements. 

• In  executable  statements. 

First,  to  examine  the  effects  of  a varying  number  of  blank  lines 
between  statements  (null  statements),  add  LOW  number  of  blank  lines 
to  the  skeleton  program.  Compile  it,  subtract  off  the  time  required  to 
compile  only  the  skeleton  program,  and  plot  the  results.  Then  add 
STEP  number  of  additional  blank  lines,  and  repeat  the  process  until 
HIGH  number  of  replications  is  reached.  The  results  which  are  plotted 
should  indicate  the  effects  of  blank  lines  on  a compiler's  performance. 

The  last  test  program  in  this  set  will  be  referred  to  as  an  "empty 
sheet"  program  and  will  be  used  in  other  tests. 

To  examine  the  effects  of  a varying  m.imber  of  blank  lines  in 
comment  construct  the  same  series  of  tests  as  described  for  a varying 
number  of  source  comment  lines  but  include  only  null  comments. 

Repeat  the  process  and  record  the  results. 


To  examine  the  effects  of  a varying  number  of  blank  lines  in 
declaration  statements,  add  a single  declaration  statement  to  the  skeleton 
program,  compile  it,  and  record  the  results.  Then  repetitively  stretch 
the  comment  over  several  lines  and  repeat  the  process.  For  example: 


INTEGER  A1,A2,A3  ; 
INTEGER  A1 
, A2,  A3 


...  TEST  1 // 

.. . TEST  2,  LINE  1 // 
. . . TEST  2,  LINE  2 // 
...  TEST  2,  LINE  3 // 


Lastly,  to  examine  the  effects  of  a varying  number  of  blank  lines 
in  executable  statements,  repeat  the  "stretched -out"  process  just 
described  but  replace  the  declaration  statement  with  an  executable 
statement. 

Number  of  blank  and  non-blank  characters.  To  determine  the 
compiler's  performance  as  a function  of  the  percentage  of  the  source 
language  program  devoted  to  blank  and  non-blank  characters,  construct 
three  septate  sets  of  tests  to  process  the  characters  occurring: 

• In  comments. 

• In  declaration  statements. 

• In  executable  statements. 

First,  to  examine  the  effect  of  a varying  number  of  non -blank 
characters  in  comments , take  the  largest  extended  blank  comment 
described  for  testing  a varying  number  of  blank  lines  in  comments. 

This  statement  takes  the  form: 


Line  Number 


Contents 


COMMENT 


Consider  this  test  to  be  the  skeleton  test.  Now  add  a group  of  non -blank 
characters  to  the  test,  compile,  and  record  the  results.  Continue  this 
process,  adding  groups  of  non-blank  characters  until  the  desired  number 
of  repetitions  is  reached.  If  the  language  places  an  upper  limit  on  the 
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number  of  non -blank  characters  in  a string  within  a comment,  start  a 
new  string  as  soon  as  the  maximum  length  is  reached.  The  results  of 
the  skeleton  test  should  be  subtracted  from  each  test  in  this  set  and  the 
results  plotted. 

Next,  examine  the  effect  of  a varying  nun.ber  of  blank  characters 
in  declaration  statements  by  taking  one  of  the  densely -packed  tests  for 
the  number  of  declaration  source  statements  as  the  skeleton  program. 

Now  add  a single  blank  at  every  position  of  the  program  at  which  inclusion 
is  permissible,  compile  the  program,  subtract  off  the  time  required  to 
compile  the  skeleton  program,  and  record  the  results.  Then  repeat 
this  process,  adding  another  group  of  blanks  at  the  same  places  until 
the  desired  number  of  replications  is  reached  {STEP  until  HIGH),  compile 
the  programs,  subtract  off  the  time  to  compile  the  skeleton  program, 
and  plot  the  results.  Drop  statements  at  the  end  as  necessary  to  maintain 
the  program  size  at  the  same  number  lines  for  each  test. 

Lastly,  to  examine  the  effects  of  blank  characters  in  executable 
statements,  replace  the  declaration  statement  tests  just  described  with 
executable  statements  and  perform  the  same  testing  process. 

Lengths  of  blank  character  sequences.  To  determine  the  compiler's 
performance  with  varying  lengths  of  blank  character  sequences,  construct 
three  separate  sets  of  tests  to  process  blank  characters  occurring: 

® In  comments. 

• In  declaration  statements. 

• In  executable  statements. 

First,  to  examine  the  effect  of  a varying  number  of  blank  characters 
in  a comment,  take  the  largest  non-blank  long  comment  statement  tested 
for  th'„  number  of  non-blank  characters  in  comments  and  consider  it  to 
be  the  skeleton  test  program.  After  each  character  in  the  comment 
insert  a blank,  compile  the  program,  subtract  off  the  time  to  compile 
the  skeleton  program,  and  plot  the  results.  Taer>  repeat  this  process, 
adding  another  group  of  blanks  at  the  same  places,  nncil  the  desired 
number  of  replications  is  reached  (STEP  until  HIGH).  Drop  characters 


from  the  end  of  the  comment  as  needed  to  maintain  the  program  size  at 
a fixed  number  of  lines. 

Next,  examine  the  effect  of  a va.-ying  number  of  blank  characters 
in  declaration  statements,  take  the  largest  declaration  source  statements 
test  program  and  consider  it  to  be  the  skeleton  test  program.  Place  a 
single  blank  at  every  position  of  the  program  at  which  it  is  permissable, 
compile  the  program,  subtract  off  the  time  to  compile  the  skeleton 
program,  and  plot  the  results.  Then,  as  in  the  comment  test  just 
described,  repeat  the  process,  adding  another  group  of  blanks  at  the 
same  places  until  the  desired  number  oi  replication  is  reached  (STEP 
until  HIGH),  Drop  statements  off  tl  e end  of  the  program  as  is  necessary 
to  maintain  the  program  size  at  the  same  number  of  lines  for  each  test. 

Lastly,  to  examine  the  effects  of  blank  characters  in  executable 
statements,  replace  the  declaration  statements  tests  just  described  with 
executable  statements  and  perform  the  same  testing  process. 

Punctuation,  keywords,  and  tokens.  This  series  of  tests  is 
designed  to  measure  the  performance  cf  the  compiler  as  a function  of 
the  number  of  references  to  specific  vocabulary  elements  (punctuation 
and  keywords)  and  to  user-declared  tokens  of  varying  size.  All  tests  in 
this  series  are  to  be  constructed  using  the  "empty  sheet"  test  program 
earlier  described.  This  "empty  sheet”  program  serves  as  a skeleton 
program.  It  differs  from  the  skeleton  program  described  at  the  outset 
of  this  section  in  that  the  "empty  sheet"  contains  a (generally)  large, 
predetermined  number  of  blank  lines  while  the  skeleton  contains  only 
the  minimal  amount  of  information  necessary  for  compilation  but  no 
extra  blank  lines. 

To  evaluate  the  compiler's  performance  on  punctuation  characters, 
select  one  punctuation  character,  write  a legal  statement  containing  that 
character,  and  add  the  statement  to  the  "empty  sheet"  program.  Then 
either  compile  the  program  or  compile  and  execute  the  program,  depending 
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is  a declaration  or  an  executable  statement. 


After  running  the  program,  subtract  off  the  time  to  run  the  "empty 
sheet"  program  and  plot  the  results.  Continue  to  perform  this  process 
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while  increasing  the  number  of  usages  of  the  punctuation  character  until 
the  "empty  sheet"  is  filled  up.  Then  select  another  punctuation  character 
and,  again,  repeat  the  testing  process.  Examples  of  AED  punctuation 
characters  include: 

+ _*/  = ,$$=$//$/$ 

Next,  to  evaluate  the  compiler's  performance  on  keywords,  perform 
the  same  tests  as  just  described  but  repeat  usage  of  a keyword.  Some 
examples  of  AED  keywords  are: 

ABS 

AND 

COMMON 

DO 

POINTER 

PRESET 

UNTIL 

WHILE 

To  evaluate  the  compiler's  performance  on  user -defined  tokens, 
construct  two  separate  sets  of  tests  to  examine: 

• Declaration  statements. 

• Executable  statements. 

For  user -defined  tokens  in  declarations,  construct  a test  program 
consisting  of  declarations  of  symbols  one  character  in  length,  compile 
the  program,  subtract  off  the  time  necessary  to  compile  the  "empty 
sheet"  program  which  serves  as  a skeleton,  and  plot  the  results.  Repeat 
this  process,  gradually  increasing  the  symbol  length  to  the  maximum 
permitted  by  the  language.  Before  constructing  the  first  test,  leave 
enought  blank  space  at  the  end  of  the  program  so  that  as  the  symbol 
length  increases,  the  program  does  not  exceed  the  capacity  of  the 
"empty  sheet.  " 
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To  evaluate  the  t.  Tect  of  user -defined  tokens  in  a program  containing 
both  declarations  and  executable  statements,  construct  a test  program 
consisting  of  the  declaration  of  a symbol  and  a single  executable  statement 
referencing  the  symbol.  In  AED,  this  could  take  the  form: 

BEGIN 

INTEGER  A ; 

EXTERNAL  A ; 

A = 2 ; 


END  FINI 

Compile  and  execute  the  program,  subtract  off  the  times  necessary  to 
compile  and  execute  the  'empty  sheet"  program  which  serves  as  a 
skeleton,  and  plot  the  results.  Repeat  the  process,  replicating  the 
executable  statement  until  the  "empty  sheet"  is  filled.  Perform  this 
test  for  symbols  varying  in  length  from  one  character  to  the  maximum 
permitted  by  the  language. 

Inclusion  of  external  program  elements.  This  series  of  tests  is 
designed  to  measure  the  performance  of  the  compiler  including  external 
program  elements.  In  AED,  this  take  the  form  of  a .INSERT  file  while 
in  J3B  this  takes  the  form  of  a COMPOOL  file.  These  tests  evaluate: 

• Number  of  included  elements. 

• Size  of  included  element. 

Construct  a program  containing  a mix  of  both  declaration  and 
executable  statements.  In  AED,  this  could  take  the  form: 

BEGIN 


INTEGER  Al,  A2  ; 

...  LINE1 

// 

EXTERNAL  Al  ; 

...  LINE 2 

// 

BOOLEAN  B1  ; 

...  LINE 3 

// 

B1  = TRUE  ; 

...  LINE4 

// 

II 

< 

...  LINE 5 

a 

END  FINI 

Consider  this  program  to  be  the  skeleton  program  for  this  series. 
Compile  it  and  record  rhe  time. 
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Now,  to  evaluate  the  number  of  included  elements,  move  the 


first  line  of  the  program  after  the  BEGIN  to  a .INSERT  file,  calling  it 
LINE1.  The  test  would  take  the  appearance: 


BEGIN 


.INSERT  LINE1  ; 
EXTERNAL  A1  ; 
BOOLEAN  B1  ; 
B1  = TRUE  ; 

A1  = 4 ; 


. ..  LINE1  // 
...  LINE 2 // 
...  LINE3  // 
...  LINE4  // 
...  LINES  // 


END  FINI 


Compile  the  new  program,  subtract  off  the  time  necessary  to  compile 
the  skeleton,  and  plot  the  result.  Repeat  the  testing  process,  placing 
each  additional  line  in  a . INSERT  file  until  every  indented  line  in  the 
above  example  has  .INSERT  before  it. 


Next,  evaluate  the  size  of  the  included  element.  Use  the  same 
skeleton  test  as  above.  Place  the  first  line  in  a .INSERT  file,  calling 
it  LINE1  as  above,  for  example.  Then  add  the  next  line,  LINE2,  to  the 
same  .INSERT  file  and  repeat  the  testing  process.  Continue  adding 
successive  lines  to  the  same  .INSERT  file  until  all  program  lines  ar 
contained  in  the  .INSERT  file  (LINE1  through  LINE5)  while  the  main 
program  contains  only: 


BEGIN 


.INSERT  LINE1  ; 


END  FINI 


A similar  series  of  tests  may  be  constructed  for  the  inclusion 
of  external  elements  into  a J3B  program  by  means  of  a COMPOOL  file. 
However,  this  series  would  have  to  conform  with  the  J3B  restrictions 
that  COMPOOL  elements  must  contain  only  declaration  statements  and 
that  the  program  including  them  must  contain  only  one  COMPOOL 
statement  (it  can  specify  several  file  names). 
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3.  Declarative  Elements 


The  class  oi  declarative  elements  test  exercises  the  declaration 
processing  functional  element  of  the  compiler.  This  includes  all  forms 
of  declarations  a6  well  as  references  to  declared  variables.  The  declara- 
tion portion  includes  declaration  of  other  types  of  program  elements  such  as 
procedures  and  labels.  Reference  tests  are  performed  only  on  variables, 
not  on  references  to  other  forms  of  program  elements.  (Procedure  calls, 
GOTO's,  etc. , are  tested  elsewhere.  ) 


There  are  four  basic  factors  which  influence  the  cost  of  declarative 
elements: 


• Scope  and  Class:  Includes  local,  global,  or  external  scope; 
static,  automatic,  or  "based"  variable  class;  procedure 
argument  scope  and  class. 

e Structure:  Includes  single  word,  array,  table,  component, 
partial  word  component.  (Switches  are  arrays  of  labels. ) 

• Data  Type:  Includes  procedure,  label,  integer,  real, 
Boolean,  pointer,  character  types. 

• Initial  Value:  Includes  all  forms  of  statements  used  to  set 
the  initial  value  of  a variable  (PRESET  in  AED). 


In  compilers  featuring  block  structuring,  the  cost  of  declarations  also 
depends  upon  whether  or  not  the  declarations  override  global  declarations 
for  the  same  spelling  or  built-in  declarations.  Similar  costs  are  incurred 
on  compilers  without  the  block  structure  feature  which  allow  re -declaration. 

The  tests  displaying  the  costs  of  declarative  elements  are  run  on 
the  compiler  only,  for  declaration  statements,  and  on  both  the  compiler 
and  the  executable  object  code,  for  the  reference  tests. 

Basic  overhead  costs.  The  term  "Declaration  Statement"  as 
used  here,  includes  all  forms  of  statement  used  to  set  the  four  above- 
mentioned  factors  of  a user-defined  identifier.  In  any  particular  language, 
the  source  language  used  to  set  these  factors  may  be  contained  in  a 
single  statement,  or  spread  out  among  various  seperate  statements.  The 
meaning  of  the  statement  may  also  depend  upon  its  context.  For  example, 
the  position  in  the  source  program  at  which  a type  declaration  is  placed 
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may  determine  its  scope.  It  is  the  purpose  of  this  set  of  tests  to 
illustrate  how  each  of  the  four  basic  declaration  factors  may  be  tested, 
using  the  AED  source  language  for  illustrations.  Other  source  languages 
would  contain  similar  tests. 


To  determine  the  actus  1 cost  of  various  constructs,  each  test 
series  in  the  total  set  begins  with  a skeleton  base  program  which  represents 
a simple  (minimal)  set  of  declarations.  Succeeding  test  programs  add 
or  modify  the  basic  setup,  and  performance  figures  are  measured  against 
the  base  values.  It  is  anticipated  that  most  (if  not  all)  such  comparison 
figures  will  be  an  incremental  amount  larger  than  the  base  figures,  and 
that  this  increment  is  a measure  of  the  difference  between  the  test  program 
and  the  base.  In  sotne  instances,  the  test  data  may  be  smaller  than  the 
base,  showing  that  the  base  is  not  a true  minimal  case,  but  the  performance 
measurement  comparisons  are  still  valid  even  in  this  unusual  case. 


Each  declaration  feature  test  is  written  as  a series  of  programs 
in  which  the  feature  to  be  tested  is  repeated  many  times.  The  first  test 
program  in  the  set  repeats  the  feature  LOW  times,  the  next  program  adds 
STEP  repetition  to  the  previous  number,  and  so  on  until  HIGH  repetitions 
are  reached  in  the  final  program  in  the  test  series.  The  integer  values 
assigned  to  LOW,  STEP,  and  HIGH  depend  upon  the  software  and  hardware 
measurement  facilities  available  on  the  particular  computer  and  operating 
system  being  used  for  the  tests. 


After  subtracting  the  base  value  from  the  test  figures,  the  results 
of  the  test  compilations  are  plotted,  and  a slope  determined.  The 
slope  of  this  line  represents  the  basic  cost  of  the  feature,  and  the 
shape  of  the  slope  \linear  or  non-linear)  shows  whether  or  not  a fixed 
cost  may  be  associated  with  each  occurrence  of  the  feature. 


Minimal  base  declaration  program  set.  Construct  a set  of 


programs  containing  repetitions  of  the  data  type  declaration  statement: 


INTEGER  A 


1 

i 


Include  sufficient  framework  to  permit  the  program  to  compile.  In 
AED,  this  program  takes  the  form: 


INTEGER  DUMMY  ; 
EXTERNAL  DUMMY  ; 
INTEGER  A1  ; 
INTEGER  A2  ; 


INTEGER  An  ; 

END  FiNI 

Since  these  tests  are  for  the  compiler  operation  only  (not  object  code 
efficiency),  the  program  need  not  be  executable,  only  compilable.  The 
use  of  the  variable  DUMMY  in  the  above  program  is  intended  to  permit 
compilation,  and  has  no  other  purpose. 

Declaration  string  test.  Construct  a comparison  set  of  programs 
in  which  all  data  types  of  the  A's  are  declared  in  a single  declaration 
("INTEGER  Al,  A2,  ...  An")  instead  of  in  separate  statements.  Spread 
out  the  declaration  list  over  the  same  number  of  lines  as  in  the  base 
program,  so  that  input/output  and  lexical  processing  costs  are  essentially 
equivalent.  Comparing  the  two  sets  of  data  shows  the  basic  cost  of 
processing  the  INTEGER  declaration  repeatedly  versus  a string  of 
declarations  in  which  the  INTEGER  mechanism  is  invoked  only  once  and 
given  a list  of  names. 

Scope  and  class  tests.  Construct  a series  of  test  which  is  similar 
to  the  base  skeleton  program,  but  modifies  the  scope  of  the  variable  in 
the  following  ways: 

• Insert  a BEGIN  - END  around  the  list  of  repeated  statements 
so  that  they  lie  within  an  inner  block. 

• Redo  both  test  series,  adding  an  EX  TERNAL  declaration 
statement  listing  all  of  the  A's,  thus  increasing  the  scope 
of  the  variables. 
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Construct  a test  series  based  upon  the  base  program  set, 
but  making  each  declared  "A"  a procedure  argument  (e.g. , 

DEFINE  PROCEDURE  F(A1,  A2,  ....  An  ) 

WHERE  INTEGER  A1  ; INTEGER  A2  ; 

. . . INTEGER  An  TOBE  . . . ) 


E 


• Construct  a test  series  based  on  the  previous  set,  but  each 
"A"  use  automatic  storage  (e.  g, , in  AED, 

DEFINE  RECURSIVE  PROCEDURE  . . . ) 


i. 


¥ 


Structure  tests  . Construct  a series  of  tests  which  show  the 
declaration  cost  associated  with  different  structures.  Using  the  base 
program  described  above,  replace  the  word  "INTEGER"  everywhere 
by  the  word  "INTEGER  ARRAY"  and  then  by  the  word  "INTEGER 
COMPONENT".  Compile  and  plot  these  test  results,  after  subtracting 
off  the  same  base  cost  figures  from  both  test  series. 


Redo  the  INTEGER  COMPONENT  test  four  times  adding  a packing 
statement  for  each  "A",  using  the  packing: 


• Single  bit. 

• Byte. 

• Half  word. 

• Other  (non -standard  machine  sub-word  configuration). 

Redo  the  four  sets  of  tests,  replacing  the  multiple  PACK  statement  by 
a single  statement  which  lists  all  of  the  "A's".  The  comparison  will 
show  the  cost  of  processing  individual  PACK  statements  versus  processing 
the  basic  declaration  data. 

Lastly,  redo  the  INTEGER  COMPONENT  tests  with  no  PACK 
statements,  but  using  the  offset  statement  to  assign  the  data  to  different 
word  locations  (the  AED  $=$  operator).  First  assign  the  component  to 
"$=$0,  " then  "$="1",  and  lastly  to  "$=$-1".  It  is  assumed  that  all 
offsets  greater  than  1 will  have  a similar  cost  to  the  "$=$!"  case. 
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Initial  value  testa.  In  most  compilers,  all  variables  have  aa 
initial  value  assigned  to  them  when  the  object  program  is  loaded  into 
memory  in  preparation  for  a run.  If  no  specific  value  is  assigned  in 
the  source  program,  a default  value  is  used.  For  example,  in  AED, 
all  integer  and  real  variables  are  set  to  0,  all  pointer  variables  aro  set 
to  NULL,  and  all  Boolean  variables  are  set  to  FALSE.  This  series  of 
tests  examines  the  compiler's  performance  in  setting  initial  value:) 
specified  in  the  source  program. 

Construct  a series  of  tests  based  upon  the  base  program,  but 
adding  the  statement 

PRESET  An  = 0 ; 


I 


I 


K 


I 

P 


for  each  "A"  in  the  program.  Re-compile  the  tests  using: 

• PRESET  A = 1 ; (non-zero) 

e PRESET  A = -1  ; (negative) 

• PRESET  A = 1 $/$2-;  (partial  word) 

Other  structure,  scope,  data  type  and  initial  value  tests.  To 
this  point,  the  INTEGER  data  type  has  been  tested  with  variations  in 
structure,  scope,  and  class  of  variable.  After  compiling  the  above  tests, 
some  impression  of  the  performance  of  the  compiler  regarding  declaration 
statement  processing  should  emerge. 

It  does  not  appear  obvious  that  these  individual  /.actors  are 
separable  for  measurement  purposes.  For  example,  the  cost  of  processing 
identifiers  which  have  external  scope  (availability  ouZside  the  compilation) 
may  differ  for  various  data  types  oi  structure,  and  the  sub-costs  due  to 
scope,  class,  structure,  initial  value  and  data  type  may  not  be  easily 
separable  by  source  program  testing  alone  (various  internal  compiler 
modifications  may  be  required  to  separate  these  costs).  Therefore,  it 
is  recommended  that  various  combinations  of  data  type,  scope,  class, 
initial  value  and  structure  be  attempted  and  thuse  test  results  compared 
with  previous  tests  r.o  determine  if  patterns  become  evident  which  would 
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allow  conclusions  to  be  drawn  regarding  individual  cost  factors.  The 
lists  of  factors  under  each  declaration  category  are  given  at  the  beginning 
of  this  section,  and  can  be  used  as  a basis  for  these  additional  tests. 

The  test  sets  should  be  patterned  after  the  above  INTEGER  tests,  using 
combinations  of  factors  which  illustrate  compiler  performance  features 
of  interest,  and  which  are  comparable  to  other  test  set  results. 

Referent  tests.  Previous  tests  in  this  series  have  considered 
various  forms  of  declaration  statements.  The  cost  of  accessing  or 
referring  to  the  data  in  various  contexts  is  coupled  to  the  declaration, 
and  is  considered  here. 

Unlike  the  declaration  statements  which  are  only  of  interest  in 
relation  to  compilation  costs,  references  to  data  have  both  a compilation 
and  an  object  code  execution  cost.  Therefore,  all  tests  in  this  series 
are  designed  to  be  compiled  and  executed. 

When  considering  how  to  construct  a series  of  referent  tests,  it 
becomes  clear  that  the  costs  of  data  references  are  in  general  not 
separable  from  the  statements  in  which  the  references  occur.  For 
example  in  the  statement  "A=A+B  the  cost  of  accessing  the  value 
for  B is  difficult  to  isolate.  The  cost  of  "A=A  can  be  determined  by 
compiling  this  portion  of  the  statement  in  isolation  and  subtracting  the 
resultant  cost  data  trom  the  cost  of  the  complete  statement.  However, 
this  leaves  the  cost  of  "+B"  which  cannot  be  further  broken  down  and 
compiled  in  isolation  to  determine  the  cost  of  the  addition  operator 
versus  the  cost  of  accessing  t'e  value  of  variable  B. 

, The  series  of  referent  lists  are  constructed  in  the  form  of  a base 
program  plus  a series  of  test  programs  that  build  upon  the  base.  Each 
test  repeats  the  statement  form  of  interest,  increasing  the  number  of 
repetitions  with  each  test  program,  just  as  in  the  declaration  series  of 
tests  discussed  above.  Each  group  of  tests  in  the  series  varies  some 
factor  of  the  referent  being  tested,  and  a comparison  of  the  test  results 
measures  performance  as  related  to  the  base  as  well  as  related  to  the 
other  tests  in  the  series. 


As  a base  program,  construct  a series  of  test  programs  which 
repeats  the  statement: 

A=A  : 

Repeat  the  program  for  LOW  to  HIGH  repetitions  of  the  statement.  The 
cost  of  the  compilation  and  execution  of  the  object  code  of  these  tests 
provides  the  base  figures  to  be  subtracted  from  all  referent  tests. 

The  referent  test  programs  are  constructed  as  follows.  Each 
test  is  built  upon  the  base  test  by  repeating  a statement  of  the  form: 

A=A  o£  (referent)  ; 

The  teats  for  various  referents  include: 
op  referent 

+ integer  and  real  literals 

+ integer  and  real  variables,  arrays,  and 

components 

AND  Boolean  literals 

AND  Boolean  variables,  arrays,  and  components 

For  components,  use  all  of  the  forms  of  packing  as  well  as  positive  and 
negative  offsets  described  under  the  declaration  test  set,  above.  Repeat 
all  tests  for  the  variables  of  the  classes  static,  automatic,  and  procedure 
arguments  (non -recursive  as  well  as  recursive). 

To  measure  referent  costs  in  the  procedure  cal!  context, 
construct  a test  set  which  uses  as  a base,  the  program  which  repeat*. 

A = F(B)  ; 

To  construct  the  test  series,  replace  the  procedure  argument  B by  all 
forms  of  permissahle  referent  (integer,  real.  Boolean,  component, 
procedure,  etc. ),  including  all  array  forms  and  packing  and  offset 
options.  Also  test  the  case  where  B is  an  argument  of  an  output  pro- 
cedure, making  this  outer  procedure  first  non-recursive  and  then 
recursive. 
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The  output  of  these  tests  clearly  includes  several  sub-costs,  but 
the  difference  between  comparable  format  tests  measures  changes  in 
referent  cost  only,  and  therefore  gives  * measure  of  referent  performance. 

4.  Scope  Definition  Elements 

Introduction.  The  class  of  scope  definition  elements  tests  exercises 
the  parsing  and  the  machine  independent  and  dependent  code  generator 
and  optimization  functional  elements  of  the  compiler.  These  tests  are 
designed  to  measure  compile  time  efficiency  and  execution  time  efficiency 
in  the  following  areas: 


• Procedure  definitions. 

• Parallel  scoping  ranges. 

• Compilation  boundaries  of  multiple  programs. 

• Declaration  levels. 

• Embedded  scoping  ranges  containing  different  types 

of  statements. 


Some  tests  are  designed  to  be  compiled  only;  others  both  compiled 
and  executed.  This  difference  is  discussed  with  each  set  of  tests. 

Also,  skeleton  programs  resulting  in  base  values  to  be  subtracted  from 
the  test  run  figures  are  discusced  with  each  set  of  tests. 

All  tests  in  this  class  are  intended  to  be  set  up  to  have  the  same 
number  of  lines;  blank  lines  should  be  inserted  wherever  necessary. 

This  restriction  is  designed  tc  neutralize  lexical  processing  aspects  of 
the  compiler  which  are  most  strongly  reflected  as  a "cost  per  line"  of 
compilation.  To  make  the  restriction  easy  to  follow,  some  of  the  tests 
are  based  on  the  "empty  sheet"  program  introduced  in  the  lexical  test 
series. 

Basic  overhead  costs.  A base  or  skeleton  program  is  constructed 
and  run  to  determine  a base  cost  figure  to  be  subtracted  from  the  results 
of  the  various  test  runs.  This  program  contains  only  those  source 
statements  which  are  necessary  tc  make  the  program  compilable  (or 
executable,  where  noted)  and  which  are  not  related  to  the  test  to  be 
performed.  The  particular  scope  definition  elements  tests  consist  of  a 
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series  of  programs  repeating  the  statement  form  to  be  tested.  The 
• statement  is  repeated  LOW  times , and  the  number  of  repetitions  is 
increased  by  STEP  until  HIGH  number  of  statements  is  processed. 

The  skeleton  program  for  the  tests  which  are  compiled  only 
in  AED,  takes  the  form: 

BEGIN 

INTEGER  DUMMY  ; 

EXTERNAL  DUMMY  ; 

END  FINI 

The  dashed  lines  indicate  the  position  where  the  additional  test  program 
statements  are  to  be  added. 

Procedure  definitions.  This  set  of  tests  is  designed  to  measure 
the  overhead  costs  of  a procedure  definition.  Construct  a set  of  programs 
containing  repetitions  of  the  AED  null  procedure  definition: 

DEFINE  PROCEDURE  A„  TOBE 

XI 

Since,  in  AED,  the  above  statement  does  not  generate  code,  this  set  of 
tests  needs  only  to  be  compiled  and  takes  the  form: 

BEGIN 

INTEGER  DUMMY  ; 

EXTERNAL  DUMMY  ; 

DEFINE  PROCEDURE  A1  TOBE  ; 


DEFINE  PROCEDURE  An  TOBE  ; 

END  FINI 

Com  ruct  all  procedure  definitions  tests  such  that  each  contains  the  same 
number  of  lines,  in  conformance  with  the  "empty  sheet"  concept 
discussed  in  connection  with  the  lexical  elements  tests. 


scoping  ranges.  This  set  of  tc-ts  is  designed  to  measure 
the  overhead  costs  of  a scoping  range.  Cons  tract  a set  of  programs 
containing  repetitions  of  the  AED  null  scoping  range.  This  feature  takes 
the  form  of  the  following  pair  of  statements: 

BEGIN  END  ; 

Since,  in  AED,  the  above  statements  do  not  generate  code,  add  repetitions 
of  the  BEGIN  - END  pair  of  statements  to  the  compil  ,'s-only  skeleton 
program.  Construct  all  parallel  scoping  range  tests  such  that  each 
contains  the  same  number  of  lines,  in  conformance  with  the  "empty  sheet" 
concept  discussed  in  connection  with  the  lexical  elements  tests. 

In  certain  other  higher  levei  programming  languages,  PL/I  for 
example,  BEGIN  - END  pairs  of  statements,  in  addition  to  procedure 
definitions,  define  the  retention  range  for  the  compiler's  allocation  of 
automatic  storage  locations.  In  evaluating  the  performance  of  such  a 
compiler,  the  set  of  tests  constructed  would  have  to  be  both  compilable 
and  executable,  and  both  the  compilation  time  and  the  efficiency  of  the 
generated  code  would  have  to  be  evaluated. 

Compilation  boundaries.  This  set  of  tests  is  designed  to  measure 
the  overhead  cost  of  splitting  a single  program  into  two  or  more  separate 
compilations.  Construct  a set  of  programs  containing  repetitions  of 
the  AED  empty  program  definition  statements; 

END  FINI  BEGIN 

As  in  the  two  previous  sets  of  tests,  the  above  statements  do  not  generate 
code,  add  repetitions  of  the  END  FINI  - BEGIN  pair  of  statements  to  the 
compile-on  , skeleton  program  so  that  it  takes  the  form: 

BEGIN  . . . PROGRAM  A1  // 

INTEGER  DUMMY  ; 

EXTERNAL  DUMMY  j 

END  FINI 


BEGEN  ...PROGRAM  An  // 

INTEGER  DUMMY  ; 

EXTERNAL  DUMMY  ; 

END  FINI 

145 


Construct  all  compilation  boundaries  tests  such  that  each  contains  the 
same  number  of  lines,  in  conformance  with  the  "empty  sheet"  concept 
discussed  in  connection  with  the  lexical  elements  tests. 

The  facility  to  compile  a sequence  of  programs  without  reinitializing 
the  compiler  is  not  present  on  all  AED  compilers.  The  test  methods 
described  here  is  applicable  to  the  AED  compiler  on  the  Control  Data 
6600  but  not  to  AED  compilers  on  either  the  Univac  1108  or  the  IBM  360. 

Declaration  levels.  The  two  sets  of  tests  described  here  are 
designed  to  measure  the  overhead  cost  of  embedded  scoping  ranges  (or 
declaration  levels).  The  first  set  examines  empty  scoping  ranges;  the 
second  non-empty. 

Construct  a set  of  programs  containing  embedded  repetitions  of 
the  AED  null  scoping  range  pair  of  statements: 

BEGIN  END  ; 

Again,  because  the  above  statements  do  not  generate  any  code,  add 
repetitions  of  the  BEGIN  - END  pair  of  statements  to  the  compile -only 
skeleton  program  so  that  it  takes  the  form: 

BEGIN 

INTEGER  DUMMY  ; 

EXTERNAL  DUMMY  ; 


BEGIN 

...  LEVEL  1 // 

BEGIN 

...  LEVEL  2 // 

BEGIN 

...  LEVEL  n /. 

END  ; 

...  LEVEL  n // 

END  ; 

...  LEVEL  2 // 

END  ; 

...  LEVEL  1 // 

END  FINI 

Construct  ail  -eats  such  that  each  contains  the  same  number  of  lines,  in 
conformance  with  the  "empty  sheet"  concept  discussed  in  connection 
with  the  r.cal  elements  tests. 
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Next,  to  test  embedded  scoping  ranges  over  non -null  statements, 
construct  a compile -only  skeleton  .program  with  a predetermined  number 
of  declaration  statements: 

BEGIN 

INTEGER  DUMMY  ; 

EXTERNAL  DUMMY  ; 

INTEGER  AO  ; 

INTEGER  A1  ; 


INTEGER  An  ; 

END  FINI 

Place  a BEGIN  - END  pair  of  statements  around  the  last  declaration 
statement  (INTEGER  An  ;),  and  recompile.  Then  place  another 
BEGIN  - END  pair  of  statements  so  as  to  include  both  the  next-to-last 
declaration  and  the  pair  just  added,  and  recompile  again.  Continue  this 
process  until  only  the  first  declaration  lies  in  the  outermost  BEGIN-END 
block  of  the  program  and  takes  the  following  form: 

BEGIN 

INTEGER  DUMMY  ; 

EXTERNAL  DUMMY  ; 

INTEGER  AO  ; 

BEGIN  ...  LEVEL  1 // 

INTEGER  A1  ; 

END  ; 


BEGIN  ...  LEVEL  n // 

INTEGER  An  ; 

END  • 

END  FINI 


Again,  construct  all  tests  such  that  each  contains  the  same  number  of 
lines. 
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Embedded  scoping  ranges  rontaining  different  types  of  statements. 
These  tests  are  designed  to  evaluate  the  performance  of  the  compiler  in 
relation  to  processing  embedded  scoping  ranges  where  the  innermost 
range  contains  different  groups  of  the  same  type  statement,  some 
executable  and  some  only  compilable.  While  the  previous  sets  of  tests 
concentrate  on  the  effect  on  the  program  of  imposing  additional  scoping 
levels,  these  tests  attempt  to  isolate  any  effect  of  outer  scoping  levels 
on  statements  at  an  inner  level. 

Specifically,  these  tests  examine: 

• Declaration  statements. 

• Executable  statements. 

• User  tokens. 

• User  tokens  redeclared. 

a Nested  procedure  definitions. 

• Labels. 

These  tests  use,  first,  the  skeleton  program  discussed  earlier 
under  basic  overhead  costs.  To  this  skeleton  each  set  of  tests  adds, 
successively,  an  increasing  number  of  similar  statements.  Then  one 
or  more  (LOW  as  explained  in  Section  1)  number  of  embedded  levels 
of  declarations  is  added  to  the  skeleton  program,  and  an  increasing 
number  of  similar  statements  is  again  added.  The  number  of  levels  of 
declarations  is  increased  (by  STEP  until  HIGH:  .umber  is  reached,  as 
described  earlier),  and  an  increasing  number  of  similar  statements  is 
added.  Thus,  these  tests  vary  first  the  number  of  similar  statements 
and  then  the  number  of  embedded  levels  of  declarations. 

To  test  the  compiler's  performance  with  a varying  number  of 
declaration  statements  within  embedded  scoping  ranges  , construct  a 
group  of  declaration  statements  of  the  form 

INTEGER  A1  ; 

INTEGER  A2  ; 


INTEGER  Am  ; 


and  add  these  to  the  innermost  embedded  scoping  range  of  both  the 
skeleton  test  and  the  tests  with  increasing  levels  of  embedded  scoping 
ranges.  These  tests  need  be  compiled  only,  since  no  object  code  is 
generated  by  the  AED  compiler  for  any  construct  tested. 

To  test  the  compiler's  performance  with  a varying  number  of 
executable  statements  within  embedded  scoping  ranges,  replace  the 
group  of  declaration  statements  in  the  previous  test  set  with  a group 
of  executable  statements.  These  take  the  form: 

A = A ; 

Add  repeated  instances  of  the  above  assignment  statement  to  the  innermost 
embedded  scoping  range  of  both  the  skeleton  test  and  the  tests  with 
increasing  levels  of  embedded  scoping  ranges.  The  same  statement 

A = A ; 

may  be  repeated  as  many  times  as  desired  since  AED  makes  no  restriction 
on  this  language  usage.  It  is  however  necessary  to  declare  A and  this 
should  be  done  in  the  outermost  block.  The  last  test  in  this  set  should 
take  the  form: 

BEGIN 

INTEGER  DUMMY  ; 

EXTERNAL  DUMMY  ; 

INTEGER  A ; 


BEGIN 


BEGIN 


BEGIN 
A = A ; 
A = A ; 

A = A ; 
END  ; 


END  ; 
END  ; 


. LEVEL  1 // 

. LEVEL  111 

. LEVEL  n // 

. ASSIGNMENT  1 // 

. ASSIGNMENT  111 

. ASSIGNMENT  m // 
. LEVEL  n // 

. LEVEL  2 // 

. LEVEL  1 // 


END  FINI 
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Since  these  tests  contain  executable  statements,  they  must  be  compiled 
and  executed,  and  both  the  compilation  time  and  efficiency  of  the  resultant 
object  code  evaluated. 

To  test  the  compiler's  performance  with  a varying  number  of  user 
tokens  within  embedded  scoping  ranges,  replace  the  group  of  statements 
in  the  basic  test  set  with  a single  declaration  statement  of  increasing 
number  of  tokens  (items  being  declared)  of  the  form: 

INTEGER  Al,  A2,  ...  Am; 

Repeat  the  process  just  described.  These  tests  need  only  be  compiled, 
since  no  ojbect  code  is  generated  by  the  AED  compiler  for  any  construct 
tested. 

Note  that  this  set  of  tests  differs  from  the  varying  number  of 
declarations  statements  tests  in  that  the  number  of  variables  is  considered 
significant,  rather  than  the  number  of  statements. 

Construct  a set  of  tests  similar  to  the  set  just  described  but 
have  each  variable  declared  in  both  the  innermost  and  outermost  scoping 
ranges  to  evaluate  the  compiler's  performance  with  a varying  number  of 
redeclared  user  tokens.  Any  observed  differences  between  the  previous 
set  of  tests  and  this  set  may  be  attributed  to  the  fact  that  the  variables 
had  already  been  declared. 

To  test  the  compiler's  performance  with  a varying  number  of 
nested  procedure  definitions  add  an  increasing  number  of  nested 
procedure  definition  statements  to  the  skeleton  test  program.  The  last 
test  in  this  set  should  take  the  form: 
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BEGIN 

INTEGER  DUMMY  ; 

EXTERNAL  DUMMY  ; 

DEFINE  PROCEDURE  Al  TOBE  BEGIN 

DEFINE  PROCEDURE  A2  TOBE  BEGIN 


DEFINE  PROCEDURE  AN  TOBE  BEGIN 

END  ; ...  PROCEDURE  An  // 


150 


END  ; 
END  ; 

END  FINI 


...  PROCEDURE  A2  // 
...  PROCEDURE  A1  // 


This  set  of  tests  needs  only  to  be  compiled,  since  no  object  code  is 
generated  by  the  AED  compiler  for  any  construct  tested. 

Lastly,  to  test  the  compiler's  performance  with  a varying  number 
of  labels,  perform  the  set  of  tests  described  for  executable  statements 
but  assign  a label  to  each  statement.  The  features  tested  for  inclusion 
to  the  skeleton  test  take  the  form: 

LI:  A = A ; 

L2:  A = A ; 


Ln:  A = A ; 

Compile  and  execute  this  set  of  tests  and  then  compare  the  results  with 
those  from  the  executable  statements  tests.  The  differences  in  per> 
formance  may  be  attributed  to  the  presence  of  the  labels. 

5.  Program  Control  Elements 

Introduction.  The  class  of  program  control  elements  tests 
exercises  the  parsing  and  machine  independent  and  dependent  functional 
elements  of  the  compiler.  These  tests  are  designed  to  be  compiled  and 
executed. 

Program  control  elements  play  an  important  role  in  overall 
compiler  performance.  This  role  is  more  or  less  important  depending 
upon  the  specific  application  for  which  the  compiler  is  being  used.  For 
example,  a "system”  program  (compiler  program,  file  system  program, 
etc. ) in  general  makes  heavier  use  of  conditional  expressions  and  Boolean 
operators  than  a "scientific"  application  program  (numberical  analysis 
and  data  reduction,  avionics  programs,  etc. ),  which  makes  heavier  use 
of  loops  and  arithmetic  operators.  In  all  cases,  however,  program 
control  statement  efficiency  is  an  important  measure  of  compiler 
performance. 
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Basic  overhead  costs.  To  make  the  plot  of  the  graphic  output 
more  sensitive,  as  many  overhead  costs  as  possible  are  subtracted  from 
the  test  figures  before  plotting.  To  determine  the  overhead  base  cost 
to  be  subtracted,  an  overhead  skeleton  program  is  constructed  which 
contains  just  the  source  statements  not  related  to  the  test  to  be  performed 
(statements  necessary  to  make  the  test  program  compilable),  plus  all 
sub-expressions  which  are  compilable  in  isolation  (sub-cost  (1)).  These 
skeleton  programs  are  compiled  and  executed  in  order  to  obtain  a "base 
cost"  figure,  as  discussed  above. 


For  example,  in  AED,  an  overhead  skeleton  program  might  be: 
BEGIN 

DEFINE  PROCEDURE  MAIN  TOBE 
BEGIN 

INTEGER  A ; 

A=A  ; 

A=A  ; 

• • • 

A=A  ; 

END 
END  FINI 


The  above  skeleton  corresponds  to  the  test  program: 


BEGIN 

DEFINE  PROCEDURE  MAIN  TOBE 
BEGIN 

INTEGER  A ; 

IF  TRUE  THEN  A=A  ; 

IF  TRUE  THEN  A=A  ; 

• • • 

IF  TRUE  THEN  A=A  ; 

END 
END  FINI 


where  the  underlined  phrases  (simple  IF  --  THEN)  are  the  forms  being 
tested. 
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Types  of  IF  tests.  IF  statement  tests  are  broken  down  into  tests 
of  the  IF  --  THEN  and  IF  --  THEN  --  ELSE  statement  forms,  and  tests 
of  the  various  THEN  and  ELSE  clause  forms.  The  same  set  of  tests  is 
intended  for  testing  both  compiler  and  resulting  object  code  efficiency, 
and  therefore  include  whatever  source  statements  are  necessary  to  permit 
their  convenient  execution,  as  well  as  the  basic  syntax  necessary  for 
compilation. 

The  description  of  each  test  program  contains  three  integers: 

LOW,  STEP,  and  HIGH,  which  represent  the  number  of  times  a particular 
construct  is  to  be  repeated  in  the  test  program.  It  is  anticipated, 
depending  upon  the  clock  accuracy  and  consistency  of  results  from 
repetition  of  the  same  test  runs,  that  these  LOW,  STEP,  and  HIGH 
integers  will  need  to  be  varied,  depending  upon  the  specific  computer 
and  operating  system  on  which  the  testing  is  conducted. 

In  each  case,  the  tests  are  designed  to  test  the  parser  and  code 
generator  portions  of  the  compiler.  The  costs  of  reading  input,  per- 
forming lexical  analyses  on  the  input  characters,  and  writing  compiler 
output  are  not  of  interest  here,  and  these  costs  are  included  in  the  base 
cost  determined  from  the  skeleton  program  and  subtracted  from  the 
test  program  results. 

Conditional  statement  forms  (IF).  This  category  covers  the 
basic  "conditional"  class.  AED  statements  are  used  as  illustrations, 
below. 

The  form  of  an  IF  construction  in  AED  is: 

IF  X THEN  SJl  ELSE  S2 

where  X is  any  Boolean  variable  or  phrase,  and  Sl^  and  S2  are  variables, 
constants,  or  phrases  whose  type  depends  upon  the  particular  form  of 
IF  construction  used.  If  the  IF  is  used  in  its  "non-valued"  form,  J§1  and 
£2.  must  have  the  type  "statement";  if  the  IF  is  used  in  its  "valued" 
form,  SI  and  S2  must  be  of  the  same  type,  and  may  take  on  whatever 
form  is  required  by  the  larger  statement  in  which  the  IF  is  nested.  For 
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example,  in  AED,  the  following  statements  illustrate  some  of  the  "valued" 
uses  of  IF: 

Pointer  1 = IF  Booll  THEN  Pointer 2 ELSE  Pointer3 

GOTO  IF  Bool2  THEN  Label  1 ELSE  Label2 

A = A + IF  Bool3  THEN  1 ELSE  2 

In  the  tests  described  below,  the  "valued"  form  of  IF  is  ignored,  since 
it  is  not  basically  a program  control  construct  and  is  not  common  among 
compiling  languages.  (For  example,  it  is  not  available  in  J3B. ) Only 
the  non -valued  II*  form  is  examined  here. 

Tests  for  IF  clause  forms.  The  IF- -THEN  statement  has  two 
sub-expressions,  with  their  associated  sub-costs: 

IF  expression!  THEN  expression2  ; 

where  expression  1 is  of  type  Boolean  and  express ion2  is  of  type  state- 
ment. Since  express ion2  is  of  type  statement,  it  can  be  compiled  in 
isolation,  and  therefore  sub-cost  (1)  resulting  from  expression  can 
be  determined.  However,  expression!  cannot  be  compiled  in  isolation, 
and  there  is  therefore  no  way  to  separate  out  its  contributed  sub-cost. 
Also,  since  the  IF  statement  will  not  compile  unless  expression!  and 
cxprcs8ion2  are  given,  there  is  no  way  to  determine  the  invariant  cost 
of  the  IF -statement  form  (sub-cost  (2)). 

Consequently,  the  test  procedure  to  be  used  in  this  case  is  as 
follows.  First  construct  a program  containing  LOW  number  of  state- 
ments of  the  form 

IF  TRUE  THEN  statement  ; 

where  statement  is  any  executable  statement  which  will  cause  the  IF 
statement  to  be  compilable  and  executable  (e.g.  , A=A).  Construct  a 
series  of  test  programs,  incrementing  the  number  of  these  statements 
by  STEP  until  a program  containing  HIGH  number  of  statements.  Compile 
and  execute  each  test  program  thus  generated.  Repeat  the  same  set  of 
tests  with  the  IF  FALSE  form,  so  that  statement  is  never  executed,  and 
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all  that  is  measured  is  the  mechanism  used  to  test  and  branch  between 
statements.  Of  course,  the  overhead  figure  subtracted  from  this  second 
set  of  test  runs  does  not  include  the  repetative  statement  execution. 

Repeat  the  above  test  series,  replacing  the  IF  TRUE  with(l)  IF  FALSE, 
and  (2)  IF  Boolean  variable,  and  tbon  (3)  with  the  expression  varl  ==  var2 
(simple  EQL  comparison).  The  test  set  need  not  be  run  using  the  other  5 
forms  of  comparison  operator,  since  it  is  assumed  that  the  difference  in 
efficiency  between  the  various  comparison  operators  is  a separate  topic 
covered  by  a separate  set  of  tests,  and  is  not  coupled  to  the  IF  statement 
efficiency. 

To  complete  the  IF  clause  test  set,  compile  and  run  the  same 
series  of  tests  using  the  compound  expression  form  Booll  AND  Bool2 
for  the  variable.  Again,  as  with  the  individual  comparison  operators, 
it  is  assumed  that  differences  in  efficiency  between  operators  and  com- 
binations of  operators  (OR,  NOT,  Booll  AND  NOT  Bool2,  etc. ) can  be 
separated  from  IF  statement  efficiency  tests;  the  operator  efficiency 
question  is  covered  by  another  set  of  tests. 

Goal  of  THEN  and  ELSE  clause  tests.  The  goal  of  this  series 
of  test.1  is  to  determine  the  interaction  costs  (sub-cost  (3))  of  the  six 
permissable  forms  of  THEN  clause:  BEGIN,  CALL,  FOR,  IF,  GOTO, 
assignment.  A separate  overhead  skeleton  program  for  each  of  the  six 
permissable  forms  is  generated,  to  subtract  off  the  effect  of  the  form  of 
THEN-  clause  used  and  thus  leave  the  effect  of  the  IF  --  THEN  portion 
only.  For  example,  the  overhead  skeleton  for  the  CALL  form  is: 

BEGIN 

DEFINE  PROCEDURE  MAIN  TOBE 
BEGIN 
CALL(  ) ; 

CALL(  ) ; 

• • • 

CALL(  ) ; 

END 

END  FINI 
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This  skeleton  corresponds  to  the  test  program: 

BEGIN 

DEFINE  PROCEDURE  MAIN  TOBE 

BEGIN 

IF  TRUE  THEN  CALL(  j ; 

IF  TRUE  THEN  CALL(  ) ; 

• • • 

IF  TRUE  THEN  CALL<  ) ; 

END 

END  FINI 

where  the  underlined  portion  is  the  construct  to  be  tested,, 

THEN  and  ELSE  clause  tests.  Construct  a series  of  tests, 
beginning  with  LOW  number  of  statements  and  increasing  this  number 
by  STEP  until  HIGH  for  each  of  the  six  forms  of  THEN  clause:  BEGIN, 
CALL,  FOR,  IF,  GOTO,  and  Assignment.  Set  the  IF  variable  to  TRUE. 
Compile  and  execute  these  tests,  as  well  as  the  overhead  skeleton 
program  corresponding  to  each  test  program.  Subtract  the  effect  of  the 
overhead  from  each  test,  to  obtain  the  desired  performance  measure. 

Repeat  the  same  series  of  tests,  replacing  each  statement  of 
the  form 

IF  variable  THEN  statement 
by  the  statement 

IF  variable  THEN  statement  ELSE  statement 

Note  that  the  overhead  skeleton  programs  need  not  be  re -compiled  or 
re-run  for  these  second  ELSE  clause  tests,  since  the  desired  overhead 
numbers  can  be  obtained  directly  from  the  first  set,  based  upon  the 
number  of  statements  executed.  Run  this  set  of  tests  twice,  first  with 
variable  set  to  TRUE,  and  then  with  variable  set  to  FALSE.  This  will 
show  any  differences  in  performance  between  the  THEN  and  the  ELSE 
portions  of  the  statement.  Use  the  same  expression  for  both  statements 
(THEN  and  ELSE). 
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FOR  Statements.  The  FOR  statement  (looping  statement)  has  the 
following  forms  in  AED: 

Form  Is  FOR  index  variable  = initial  value  WHILE  continuation 
condition  DO  loop  body  ; 

Form  2;  FOR  index  variable  = initial  value  STEP  increment  value 
UNTIL  termination  value  DO  loop  body  ; 

Form  3;  FOR  index  variable  = value , value,  value,  . . . , value 
DO  loop  body  ; “ ” 

Form  4:  WHILE  continuation  condition  DO  loop  body  ; 

An  elaboration  on  Form  3 allows  any  value  in  the  list  to  the  right  of  the  = 
to  be  any  of  the  following  three  phrases: 

• initial  value  WHILE  continuation  condition 

• initial  value  STEP  increment  value  UNTIL  termination  value 

• initial  value  STEP  increment  value  WHILE  continuation  condition 

The  goal  in  running  the  tests  on  FOR  statements  is  to  determine 
the  efficiency  of  the  FOR  loop  mechanism  used  to  accomplish  the  various 
forms  of  loops.  To  do  this,  tests  are  constructed  to  determine  the 
efficiency  of  each  form  of  FOR  statement,  working  with  each  permis sable 
form  of  initial  value,  index  variable,  increment  value,  continuation 
condition,  termination  condition,  and  loop  body. 

Tests  for  Variations  in  Loop  Statement  Operands.  Construct  a 
set  of  tests  with  LOW  to  HIGH  repetitions  of  each  of  the  looping  statement 
forms,  using  the  simplest  convenient  form  of  operands.  In  AED  this 
corresponds  to  the  four  sets  of  statements: 

FOR  1=1  WHILE  I LEQ  1 DO  1=1+1  ; 

FOR  1=1  STEP  1 UNTIL  1 DO  1=1+1  ; 

FOR  1=1, 1 DO  1=1+1  ; 

WHILE  I LEQ  1 DO  1=1+1  ; 

where  I is  declared  to  be  of  type  INTEGER.  Since  the  AED  compiler 
initializes  all  integer  variables  to  0,  each  loop  statement  causes  the  DO 
portion  (1=1+1)  to  be  executed  twice;  thus  each  set  of  test  results  may 
be  compared  to  each  other  set  to  determine  relative  efficiency  of  the 
equivalent  construct. 
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Next,  determine  the  base  value  to  be  subtracted  from  each  set  of 
tests.  This  is  done  by  compiling  and  executing  a series  of  programs 
containing  n*2  repetitions  of  the  statement  "1=1+1"  (the  DO  expression), 
where  n is  the  number  of  loop  statements  in  the  test  program,  plus  n 
repetitions  of  the  statement  "1=1",  (the  FOR  expression).  The  STEP, 
UNTIL,  and  WHILE  expressions  are  not  separable. 

To  test  various  other  forms  of  operands,  next  vary  each  operand 
according  to  the  following  sequence.  Consider  the  statement  forms: 

FOR  i=e  STEP  f UNTIL  g DO  s ; 

FOR  i=e  WHILE  x DO  s ; 

FOR  i=e  i,  e2,  . . . en  DO  s ; 

WHILE  x DO  s ; 

Each  of  the  lower-case  letter  codes  represents  an  operand  class  that  is 
to  be  varied  to  gather  performance  measurements: 


Letter  Code  Variations  Tested 


I 


I 

x 


I 


i Structure  and  Data  Type 

e,f,  g Literal /Variable  Structure  Type 

x Boolean  Data  Type 

s Statement  Type 

Construct  a series  cf  tests  for  each  of  the  four  loop  statement  forms, 
using  the  following  variations,  one  at  a time,  in  place  of  the  correspond- 
ing letter  code  shown  above.  For  all  but  the  single  letter  code  being 
examined,  use  the  basic  (simplest)  case  employed  at  the  beginning 
of  this  section. 

Forms  of  "i"  Structure  and  Data  Types; 

a.  Simple  integer. 

b.  Subscripted  integer  array  element. 

c.  Integer  bead  component. 

d.  Simple  real  variable. 

e.  Subscripted  real  array  element. 

f.  Real  bead  component. 
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g.  Simple  pointer  variable. 

h.  Subscripted  pointer  array  element. 

i.  Pointer  bead  component. 

j.  Simple  Boolean  variable. 

k.  Subscripted  Boolean  array  element. 

l.  Boolean  bead  component. 

General  form  of  "e"  (or  "e^"),  "f"  (or  "fj"),  or 

"g"  (or  ,!gi")  literal  or  variable: 

a.  Single  literal,  or  non -subscripted  variable  w.th  the  same 
data  type  as  i. 

b.  Other. 

Form  of  "x"  boolean  data  types: 

a.  Simple  Boolean. 

b.  Other. 

Form  of  "s"  statement  types: 

a.  BEGIN . 

b.  CALL, 

c.  FOR. 

d.  IF. 

e.  GOTO . 

f.  Assignment. 

Tests  of  loop  execution  efficiency.  The  above  test  series 
examines  the  cost  of  the  various  forms  of  operands  used  with  looping 
statements.  The  run-time  cost  of  the  loop  mechanism  itself  is  determined 
by  constructing  a series  of  tests  containing  a single  loop  statement, 
specifying  an  increasingly  larger  number  of  iterations  around  the  loop 
(e.g.,  UNTIL  10,  UNTIL  100,  UNTIL  1000,  etc.).  Subtract  the  base 
value  derived  from  the  test  run  which  contained  the  proper  number  of 
repetitions  of  the  statement  "1=1+1"  to  isolate  the  cost  of  the  loop  action. 
Run  the  tests  for  all  four  forms  of  loop  statement,  and  for  all  forms  of 
operand  listed  above.  Li  ;his  series,  the  only  meaningful  efficiency 
measure  is  on  the  code  generator  output  (data  resulting  from  the  run, 
not  the  compilation). 
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To  test  the 


Procedure  and  function  call  mechanism  testa. 
procedure  and  function  call  mechanisms  of  the  compiler,  construct  the 
following  series  of  tests.  Repeat  the  simplest  form  of  procedure  and 
function  call  LOW  to  HIGH  times,  creating  two  series  of  test  programs 
and  a resultant  graph  showing  the  slope  of  the  individual  test  program 
results.  The  "simplest"  forms  are 

F(  ) ; 

for  a procedure,  and 
A=F( ) ; 

for  a function  call. 

Use  a program  format  containing  only  the  minimum  number  of  statements 
required  to  permit  compilation  and  execution  of  the  test  series,  and 
subtract  the  cost  of  the  skeleton  version  of  this  program  as  a base  value. 
Compile  and  run  the  tests  using  the  simple  form  and  then  the  recursive 
form  of  procedure  and  function  definition.  Rerun  the  tent  series  using 
all  other  permissable  forms  of  calls  (Fortran  and  COBOL  compatible 
forms,  internal  versus  external  forms,  etc.  )„ 

More  complex  tests  of  function  and  procedure  calls  used  with 
various  language  constructs  and  environments  are  not  considered  here; 
they  are  discussed  in  relation  to  each  individual  context  (IF- -THEN, 

FOR,  etc. ).  Also,  tests  of  procedure  and  function  argument  and  output 
value  transmission  are  convered  under  the  test  series  discussed  in 
Section  6. 


Other  program  control  tests.  Unconditional  transfer  statements 
comprise  the  final  set  of  program  control  statements  to  be  tested.  These 
include  labels,  transfer  statements  (GOTO  in  AED),  and  switches.  Unlike 
the  conditional  (IF)  statement  and  the  loop  (FOR)  statement  which  are 
tied  to  Boolean  phrases  of  various  types,  unconditional  transfers  are 
completely  separable  from  other  language  forms. 


6 


To  construct  an  efficiency  test  for  unconditional  transfer  statements, 
write  a series  of  test  programs  as  follows: 

• Write  a test  program  containing  transfers  to  the  next 
statement: 

GOTO  LI  ; 

LI  : GOTO  L2  ; 

L2  ; GOTO  L3  ; 

(etc.) 

Include  enough  of  these  to  permit  sufficient  compiling 
and  execution  time  to  be  measurable. 

Compile  and  run  this  test,  subtracting  the  overhead 
skeleton  cost.  Continue  to  increase  the  number  of 
transfers  and  run  tests  until  a pattern  is  evident. 

• Write  a second  series  of  tests  based  on  the  first,  which 
includes  a single  executable  statement  (such  as  "A=A") 
before  each  transfer  statement.  (This  should  detect 
control  sequence  optimization. ) Compiler  and  run  these 
tests,  subtracting  off  the  overhead. 

• Repeat  the  entire  series  of  tests  described  above, 
replacing  the  simple  transfer  statements  with  switch  calls 
which  have  the  same  logical  effect.  Use  integer  literals 
in  the  switch  calls.  For  example,  in  AED,  the  repeated 
statements  of  the  first  test  set  would  be: 

SWITCH  W = LI,  L2,  L3,  ... 

GOTO  W(l)  ; 

LI  : GOTO  W(2)  ; 

L2  : GOTO  W(3)  ; 

(etc) 

• Repeat  the  preceding  switch  tests  by  replacing  the  integer 
literals  by  all  other  legal  forms,  such  as  integer  components, 
arguments,  etc. 

• Construct  a series  of  tests  for  transfer  statements  used  as 
procedure  arguments.  This  test  is  accomplished  by 
defining  two  procedures  aid  transferring  control  back  and 
forth  between  the  two  programs.  For  example,  in  AED 
this  would  be: 
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DEFINE  PROCEDURE  MAIN  TOBE 
BEGIN 
PROC(Ll)  ; 

LI  ; PROC(L2)  ; 

L2  : PROC(L3)  ; 

(etc) 

DEFINE  PROCEDURE  PROC(L)  WHERE  LABEL  L TOBE 
GOTO  L ; 

Include  sufficient  numbers  of  these  call/transfer  sequences 
to  provide  significant  timing  data.  Compile,  execute,  and 
subtract  overhead  values  from  these  tests.  Rerun  the 
tests  passing  the  target  label  through  2,  3,  4,  etc. , levels 
of  nest  depth.  Lastly,  rerun  the  tests  using  recursive 
procedure  forms,  rather  than  the  simple  procedure 
mechanism. 

Finally,  it  is  desired  to  test  the  non-lexical  performance  features 
of  labels  (lexical  features  are  examined  in  Section  2).  The  major  such 
performance  feature  involves  the  code  generator  logic  employed  in  its 
machine  register  usage  memory.  In  the  simplest  logic  design,  each 
label  occurrence  causes  all  register  memory  in  the  compiler  to  be 
cleared,  so  that  code  must  be  generated  to  load  a register  the  next 
time  a particular  value  is  needed  in  the  register.  A more  sophisticated 
code  generator  performs  sufficient  flow  analysis  to  determine  that 
certain  register  memory  need  not  be  cleared,  and,  if  a needed  value 
was  already  in  a particular  register,  it  need  not  be  re -loaded  because 
of  the  occurrence  of  the  label. 

To  test  this  code  generator  feature,  construct  a test  program 
which  repeats  the  pattern 

LO  : X = COMP(P)  ; 

LI  : X = COMP(P)  ; 

(etc) 

Repeat  this  labeled  statement  form  LOW  to  HIGH  time  * t * 1 * >tid 
run  this  test  series,  and  then  rc -compile  and  re-run  the  identic, 
programs,  except  remove  all  statement  labels.  Subtract  the  ba^o 


values  obtained  by  compiling  and  running  a program  containing  the  same 
number  o£  repetitions  of  the  statement 

X = X ; 

The  difference  between  the  labeled  and  non-labeled  versions  of  the  test 
illustrate  the  desired  code  generator  performance  measure. 
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6.  Data  Manipulation  and  Computation  Tests 


The  class  of  data  manipulation  and  computation  tests  exercise  a 
portion  of  the  parsing  and  code  generation  programs  of  the  compiler. 

The  tests  measure  performance  in  handling  the  various  data  manipulation 
operators,  as  used  in  varioits  environment.  All  tests  are  designed  to 
be  compiled  and  executed;  skeleton  programs  resulting  in  base  values 
to  be  subtracted  from  the  test  run  figures  are  discussed  with  each  set 
of  tests. 


r 


Arithmetic  assignment  operator.  The  simplest  form  of  arithmetic 
data  manipulation  is  the  assignment  statement  A = B;.  The  first  series 
of  tests  examines  the  efficiency  of  this  simple. assignment  form.  For 
this  series  of  tests,  we  are  interested  only  in  the  various  means 
employed  by  the  code  generator  for  storing  arithmetic  data.  In  particular, 
we  are  interested  in  the  interaction  between  the  "="  operator  and  the 
right-hand  side  (B).  Therefore,  the  series  of  tests  is  based  upon 
variations  of  B which  may  cause  variations  in  the  code  generated  for 
the  assignment  operation,  such  as  a "store  zero"  instruction  to  implement 
the  statement  A - 0;.  (The  left-hand  side  of  the  is  tested  in  a 
separate  set  of  tests,  described  later  in  this  section. ) 

The  tests  consist  of  a series  of  programs  repeating  the  statement 
form  to  be  tested.  The  statement  is  repeated  LOW  times,  and  the 
number  of  repetitions  is  increased  by  STEP  until  HIGH  number  of 
statements. 

The  first  set  of  tests  examines  all  forms  of  literals.  The  specific 
statement  forms  to  be  tested  are: 

• A=0  ; (integer) 

• A=1  ; (integer) 

• A=  -1  ; (integer-negation) 

• R=0  ; (real) 

• R=l.  ; (rsal) 

• R=  - 1 ; (real -negation) 

• B=TRUE  ; (Boolean) 
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• B=FAI.S£  ; (Boolean) 

• P=NULL  ; (Pointer) 

• Other, 

where  the  class  "Other"  includes  any  other  special  forms  peculiar  to  the 
compiler  being  tested  (e.g.  0's  in  bit  strings,  blanks  in  character 
strings,  etc.). 
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A single  overhead  skeleton  program  is  used  for  all  of  the  above 
tests,  which  consists  of  the  minimum  required  for  compilation  and 
execution.  In  AED,  this  is: 

BEGIN 

DEFINE  PROCEDURE  MAIN  TOBE 
BEGIN 

INTEGER  A ; 

A = 0 ; 

END  ; 
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END  FINI 

Construct  a second  series  of  tests  similar  to  the  above  set,  except 
using  all  other  permissible  structure  and  data  types  of  variable  instead 
of  literal  on  the  right  of  ch,*.  "=". 

This  includes  the  following  forms: 

• A=B  (all  types,  integer,  Boolean,  real,  pointer,  etc.  ) 

• A=AR(1)  (all  types  of  array,  using  both  an  integer  variable 
and  a literal  for  I,  and  including  as  many  levels  of 
subscripting  as  permitted) 

• A=COMP(P)  (bead  or  table  item  of  all  types,  positive  and 
negative  offset  and  packing) 

Test  the  above  forms  for  B,  AR,  I,  COMP,  and  P as  local  variables, 
arguments  of  procedures,  and  arguments  of  recursive  procedures. 

For  any  single  test,  make  only  one  item  an  argument,  to  isolate  the 
effect  of  the  mechanism. 
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Function  call  test.  Construct  a series  of  tests  to  examine  the 
cost  of  storing  the  result  of  a function  call.  This  test  is  the  same  as  the 
above  set,  except  that  the  form  A=F  ( );  is  repeated  in  each  test  program, 
and  the  base  value  subtracted  from  the  test  set  includes  the  repeated 
calls  on  F (F{  ) ; F(  ) ; etc. ) to  isolate  just  the  cost  of  the  A storage 
mechanism.  Use  all  legal  types  for  A and  F (integer,  real,  etc. ) and 
make  A of  the  same  type  as  F. 


Right  hand  side  binary  operator  test.  Next,  test  the  cost  of  binary 
arithmetic  operators  used  on  the  right  hand  side  of  the  "=".  Construct  the 
following  series  of  tests,  beginning  wifc’i  LOW  number  of  repetitions  and 
increasing  the  number  by  adding  STEP  new  repetitions  until  HIGH.  Use  the 
minimum  basic  form  of  program  which  will  allow  the  test  to  be  compiled  and 
executed.  In  AED,  this  would  be: 

BEGIN 

DEFINE  PROCEDURE  MAIN  TOBE 
BEGIN 

INTEGER  A ; 

A = A oja  A ; 

A = A oj>  A ; 

A = A oja  A ; 

END 

END  FINI 

The  overhead  skeleton  program  for  these  tests  replaces  the 


A = A ojj  A ; 


by  the  form 

A = A ; 

This  skeleton  program  base  value  subtracted  from  each  test  program 
thus  leaves  the  cost  of  oja  A,  which  includes  the  three  sub-costs:  the 
cost  of  evaluating  A,  the  invaviant  cost  of  the  0£,  and  any  residual 
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type  of  A. 
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The  specific  test  programs  to  be  compiled  and  executed  are: 

• Five  sets  of  tests,  of  the  form  A = A oj>  A,  with  op  being  +, 

/ and  **.  Use  an  integer  variable  name  for  A. 

• A second  set  of  five  tests  of  the  same  form  as  above, 
using  a real  variable  name  for  A instead  of  integer. 

• A third  set  of  tests  of  the  same  form,  using  other  types 
of  variables  for  A.  In  AED,  this  would  include  a small 
set  of  pointer  arithmetic  constructs;  in  other  languages 
it  might  include  bit -arithmetic,  etc. 

• A series  of  tests  of  the  same  form  using  other,  special 
forms  of  binary  operator  for  oja.  This  set  includes  the 
operators  for  shifting  (R.S.  and  L.S.  in  AED,  SHIFTR 
and  SHIFTL  in  J3B)  and  logical  masking  and  combining 
(.A.  for  AND,  .V.  for  OR,  etc.) 

• A set  of  tests  of  the  form  A = B oj>  C,  using  special 
literals  such  as  1 and  2 for  B and  C.  (The  code  generated 
for  manipulating  these  particular  literals  may  be  quite 
unique). 

Include  tests  for  the  following  specific  forms: 


• A + 1,  and  1 + A. 

• A - 2,  and  1 - A. 

• A * 2,  and  2 * A. 

• A/2,  and  1/A. 

• A**2,  and  e**A  (e=2.  71828. . . ). 

• A oj>  Other  Literal,  and  Other  Literal  op  A. 

Use  first  integer  and  then  real  A and,  lastly,  any  other  type  of  variable 
which  produces  a legal  construct  in  the  language  (e.g.  , P = P + 1, 
with  P of  type  pointer). 


In  all  of  the  above  tests,  the  base  value  to  be  subtracted  is 


obtained  by  creating  a skeleton  program  which  repeats  the  statement  of 
the  form  A = A.  Note  that  a different  skeleton  program  must  be 
generated  for  each  data  type  used  for  A.  In  tne  final  test  series  invol\  Jig 
literals,  the  same  base  value  is  used  for  both  permutations  (e.g.  , the 
same  base  value  derived  by  repeating  A = A,  is  used  for  both  A + 1 
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Left  hand  side  of  assignment  statement.  Construct  a series  of 
tests  to  examine  all  legal  forms  of  referent  permitted  on  the  left  hand  j 

side  of  an  assignment  statement,  thus  illustrating  the  parsing  and  code  j 

generation  actions  performed  for  the  "="  operator.  Include  the  following 

forms:  ! 

i 

• Simple  variable  ( A=  ).  J 

l 

• Subscripted  Variable  ( AR(I)  =,  AR(Literal)  =,  AR(expression)  = ). 

• Bead  or  Table  Item  Component  ( COMP(PTR)  = ). 

If  multiple  subscripting  is  available,  the  subscripted  variable  form  is 
elaborated  to  show  all  possible  combinations  of  variable,  literal,  or  ; 

expression  for  each  subscript.  ; 

4 

For  each  test  in  the  set,  repeat  one  of  the  above  forms  LOW  number  l 

of  times,  increasing  by  STEP  until  HIGH.  For  the  right  hand  side  of  the  i 

statement  use  the  simplest  form  that  permits  compilation  and  execution  j 

of  the  test  (A=A,  AR(I)  =A,  etc. ). 

The  statement  form  left-expression  * right-expression  is  not 
separable,  for  purposes  of  obtaining  a base  value.  That  is,  neither 
left-expression  nor  right-expression  can  be  compiled  in  isolation. 

Therefore,  the  skeleton  program  for  this  set  of  tests  consists  of  the 
required  compilation  framework  plus  a single  "A  = A"  statement  to 
permit  the  skeleton  program  to  compile  and  execute.  The  skeleton 
program,  in  AED,  is: 

BEGIN 

DEFINE  PROCEDURE  MAIN  TOBE 
BEGIN 

INTEGER  A ; 

A = A ; 
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• All  forms  of  COMP  offset  and  packing. 

• All  combinations  of  non-recursive  and  recursive  procedure 
arguments  (for  AR,  1,  COMP,  etc. ). 

If  permitted  by  the  language  being  tested,  also  test  the  forms 


F(  ) = 

for  setting  the  values  of  functions. 

Strings  of  arithmetic  operations.  So  far,  the  test  programs  have 
examined  only  single  occurrences  of  a particular  operator.  For  example, 
the  statement  A = A + A has  been  examined,  but  the  effect  of  a string  such 
as  A = A + A + A,  orA  = A + A + A+A,  etc.  has  not  been  examined. 

It  is  true  that  in  some  instances,  using  some  particular  computer  hardware 
designs,  a compiler  might  take  advantage  of  the  fact  that  a string  of 
operators  is  specified,  and  thus  compile  a more  efficient  object  code 
sequence.  Indeed,  sequences  involving  and  "/"  quite  frequently 
result  in  interesting  patterns  of  object  code,  since  products  and  dividends 
commonly  occur  in  separate  hardware  registers , and  the  opportunities 
for  compiler  object  code  optimization  are  clearly  evident,  especially 
taking  into  account  the  commutivity  of  source  code  operator  /operand 
sequences. 

However,  the  set  of  tests  to  evaluate  these  types  of  operator 
strings  and  sequences  is  beyond  the  scope  of  the  present  effort,  especially 
in  light  of  the  fact  the  "system -type”  applications  (compilers,  file 
systems,  etc. ) make  very  little  use  of  arithmetic  operator  strings,  and 
the  evaluation  of  their  efficiency  for  system  programming  applications 
is  of  little  importance  compared  to  other  forms  of  evaluation  considered 
here.  Arithmetic  operator  strings  are  therefore  not  included  in  the  set 
of  tests  described  here,  but  are  left  for  future  follow-on  efforts  to 
consider. 


s 
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Boolean  expression  testa.  The  set  of  Boolean  expression  tests 
closely  parallels  the  arithmetic  expression  tests  described  above.  The 
Boolean  tests  are  intended  to  examine  the  compiler's  parsing  and  code 
generation  handling  of  Boolean  forms  of  assignment  and  data  manipulation, 
using  both  literals  and  variables  as  operands.  As  in  the  arithmetic  tests, 
we  are  interested  primarily  in  the  handling  of  the  Boolean  operators, 
both  as  a fixed  cost  for  each  operator  and  as  the  expense  of  the  inter- 
action between  the  operator  and  its  environment.  The  cost  of  different 
forms  of  data  referencing  and  retrieval  are  not  considered  here;  these 
costs  are  covered  in  a separate  set  of  tests. 

As  in  the  case  of  the  arithmetic  tests,  a series  of  Boolean  test 
programs  is  constructed,  where  each  program  repeats  a statement  to 
be  tested  a certain  number  of  times.  The  first  test  contains  LOW  number 
of  repetitions,  and  these  are  increased  by  STEP  number  of  repetitions  for 
each  succeeding  test,  until  HIGH  number  of  repetitions  is  reached.  A 
"base  value"  is  determined  by  writing  one  or  more  overhead  skeleton 
programs  and  compiling  and  executing  these  skeletons.  The  base  value 
thus  derived  is  then  subtracted  from  the  figures  determined  from  each 
test  compilation  and  run.  A plot  of  these  final  figures  then  shows  a slope 
(expected  to  be  linear  in  most  cases)  which  characterizes  the  cost  of 
the  feature  being  tested. 

Use  of  single  Boolean  literals.  The  first  series  of  tests  evaluates 
the  cost  of  the  Boolean  literals  TRUE  and  FALSE.  To  test  these  literals, 
construct  a series  of  tests  containing  LOW  to  HIGH  repetitions  of  the 
statement  A = TRUE,  where  A is  a Boolean  variable.  Since  neither 
A nor  TRUE  are  compilable  in  isolation,  the  overhead  skeleton 
program  for  this  series  of  tests  consists  of  just  the  basic  statements 
necessary  to  permit  compilation  and  execution.  In  AED,  this  is 

BEGIN 

DEFINE  PROCEDURE  MAIN  TOBE 

BEGIN 

BOOLEAN  A ; 

A = TRUE  ; 
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END  ; 

END  FINI  ; 

Note  that,  in  AED,  at  least  one  executable  statement  is  required  to  permit 
compilation,  and  the  skeleton  program  therefore,  contains  the  single 
statement  "A  = TRUE". 

Repeat  the  above  test  set,  replacing  A = TRUE  by  A = FALSE 
to  determine  the  assignment  of  a Boolean  variable  to  FALSE.  The 
results  of  this  test  may  be  compared  to  the  TRUE  test,  to  determine 
any  differences  in  cost  (one  of  the  two  forms  may  take  advantage  of  a 
"store  zero"  operation,  for  example). 


i • 


Use  of  Boolean  Variables.  Repeat  the  above  series  of  tests, 
replacing  the  repeated  statement  by  A = B where  B is  a Boolean 
variable.  Construct  tests  to  show  the  cost  of  the  assignment  operator  for 
each  of  the  following  forms  of  Boolean  variable,  B: 

• A = B (simple  variable). 

• A = BA  (I)  (Boolean  array  element  --  use  variable  and 
literal  for  1,  and  use  as  many  subscripts  as  permitted. 

• A = COMP  (P)  (Boolean  component  or  table  item). 

Conduct  series  of  tests  for  all  legal  data  types  for  B,  BA,  and  COMP 
(integer,  real,  pointer,  etc. ) and  for  B,  BA,  I,  COMP,  and  P as 
simple  and  as  recursive  procedure  arguments.  Make  only  one  item 
at  a time  an  argument  to  isolate  the  desired  cost.  Use  the  sam>’.  skeleton 
program  base  value  as  for  A = Literal  in  all  cases. 

Boolean  operator  tests.  The  series  of  Boolean  operator  tests 
is  designed  to  determine  two  costs:  the  invariant  cost  of  the  use  of 
the  Boolean  operator  itself,  and  the  interactive  cost  of  using  the  operator 
with  its  right  and/or  left  context,  in  various  environments.  Use  of  the 
operator  in  conjunction  with  loops  and  conditionals  (IF  and  FOR)  is  not 
covered  here;  those  tests  are  discussed  in  Section  5. 
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The  following  forms  of  Boolean  operator  are  covered  by  the 


\ • Predicates  (e.  g. , A >5). 

£ 

i e Unary  operators  (e,  g. , NOT  A). 

| • Binary  Operators  (e.  g. , A AND  B). 

I As  in  the  case  zi  arithmetic  operators,  strings  of  operators  (e.g. , 

\ A AND  B OR  C AND  NOT  D)  are  somewhat  more  common  in  system 

- programs  than  arithmetic  operator  strings,  they  are  still  not  of 

i major  importance,  and  the  complex  series  of  tests  which  would  be 

\ required  to  test  all  possible  strings  of  Boolean  operators  of  interest, 

« 

( is  clearly  beyond  the  scope  of  the  present  study. 


I 


I 


r 


Common  form  for  all  boolean  operator  tests.  All  Boolean 
operator  tests  (predicate,  unary,  and  binary  operators  forms)  employ 
the  same  form  of  repetitive  assignment  statement,  which  is  repeated 
LC  W times  in  the  first  test  program,  and  repeated  an  additional  STEP 
times  for  each  succeeding  test  until  HIGH  number  of  repetitions  is 
reached.  The  repeated  statement  takes  the  form: 

A = (form  to  be  tested  ; 

and  uses  the  lepeated  form: 

A = A ; 

for  predicate  forms,  and  for  all  other  forms  in  the  overhead  skeleton 
program,  to  obtain  the  base  value  to  be  subtra-  ted  from  the  test  results. 


Predicate  tests.  The  predicate  form  includes  all  comparisons 
between  variables  and  literals  of  all  types.  In  ALD,  this  class  of 
statement  takes  the  form: 

A = A predicate  literal; 

or 

A _ A 31 . 

n - a pi  cuicaic  vauaui e , 
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By  using  the  base  value  derived  from  a skeleton  program  containing 
repetitions  of  the  statement  A = A;,  the  test  results  give  the  cost  of 
predicate  literal  or  predicate  variable.  More  specifically,  this  cost 
represents: 

(1)  The  cost  of  accessing  the  literal  or  variable  value. 

(2)  The  invarient  cost  of  the  predicate. 

(3)  The  cost  of  the  interaction  between  the  predicate  and  the 
literal  or  variable  in  the  given  context. 

(4)  The  cost  of  the  interaction  between  the  left  hand  side 

and  the  predicate  (the  cost  of  the  A predicate  interaction) 
in  the  given  context. 

These  four  cost  factors  are  not  separable,  since  none  of  the  portions  of 
the  statement  can  be  further  broken  down  and  compiled  in  isolation. 

To  create  a set  of  data  results  representing  the  sum  of  these 
four  costs,  construct  a series  of  test  programs  containing  from  LOW 
to  HIGH  number  oi  repetitions  of  the  statement  form: 

A = A.  predicate  (variable  or  literal); 

Use  the  predicate  forms: 

• = = (EQL). 

• = (NEQ). 

e < (LES) . 

• > (GRT). 

• > = (LEQ). 

• > = (GEQ). 

Construct  a set  of  tests  using  all  legal  types  of  variable  for  A (integer, 
real,  pointer,  etc.  ) as  compared  to  all  legal  literal  forms  (0,  1,  NULL, 
TRUV  FALSE,  etc.  ) and  all  legal  variable  structure  and  data  type 
forms.  The  variable  forms  include: 

• A (Simple  variable’,. 

• AA(1)  (array). 

• COMP  (P)  (component  or  table  item). 
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for  all  types  of  these  variables  (integer,  real,  etc. ) and  using  the  local 
procedure  argument,  and  recursive  procedure  argument  form  for  A, 

AR,  I,  COMP,  and  P. 

Unary  operators.  The  only  Boolean  unary  operator  is  NOT. 

This  series  of  tests  is  designed  to  test  the  par.sing  and  code  generator 
performance  of  the  NOT  operator  in  all  of  the  various  contexts  in  which 
it  is  properly  used. 

Since  NOT  always  precedes  a complete  Boolean  expression,  it 
is  possible  to  separate  its  cost  from  the  remainder  of  the  statement  in 
which  it  appears.  More  specifically,  consider  the  statement 

A = NOT  B: 

Subtracting  the  effect  of  the  statement 
A = B; 

leaves  the  following  costs: 

(1)  The  invariant  effect  of  the  use  of  NOT. 

(2)  The  interactive  cost  of  the  NOT  operator  in  its 
context  between  the  "="  and  toe  "B". 

These  two  subcosts  are  not  separable.  However,  if  the  use  of  NOT  in 
several  other  contexts  exhibits  an  essentially  identical  cost,  the  inter- 
active context  cost  ( (2),  above),  can  be  considered  to  be  negligible. 

To  test  the  NOT  operator,  construct  a series  of  tests  beginning 
with  LOW  repetitions  of  the  NOT  statement  to  be  examined  and  increasing 
the  number  of  repetitions  by  STEP  until  HIGH.  Use 

A = expression; 

for  the  repetitive  statement,  using  the  following  expressions: 

o NOT  A (Preceding  a Boolean  variable). 

• NOT  AR(I)  (Preceding  an  array  element). 

• NOT  COMP  (P)  (Preceding  a component  or  a table  item) . 

• NOT  (I  = = J)  (Preceding  a predicate  phrase). 

• NOT  B AND  A (Preceding  a variable  within  an  expression). 
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• A AND  NOT  (B  = = C)  (Preceding  a predicate  in  an  expression) 

• NOT  (A  AND  B)  (Preceding  an  expression). 

• NOT  F ( ) (Preceding  a Boolean  function). 

• Any  other  legal  construct  using  NOT. 

For  the  array  form,  use  both  a variable  and  a literal  for  the  index,  and 
repeat  the  tests  for  multiple  subscripts,  using  all  combinations  of 
variable  and  literal  subscript  values,  up  to  the  maximum  number  of 
subscripts  permitted.  Repeat  the  entire  set  of  tests,  using  both  non- 
recursive and  recursive  procedure  arguments  for  each  variable  used  in 
the  phrase  following  the  NOT. 

Binary  Operator  Tests.  The  class  of  binary  Boolean  operators 
includes: 

• AND. 

• OR  (Inclusive). 

• XOR  (Exclusive). 

• EQV  (Equivalence) . 

• IMP  (Implication). 

On  a given  compiler,  not  all  of  these  may  be  available,  but  tests  should 
be  run  on  as  many  as  are  permitted. 

To  obtain  the  desired  test  data,  compile  and  execute  a set  of 
repetitive  statement  is: 

A = expression  OPERATOR  expression; 

where  OPERATOR  is  one  of  the  above,  and  the  expressions  are  various 
combinations  of  Boolean  literal,  variable,  predicate,  suid  compound 
expression  forms  designed  to  provide  varying  contexts  for  the  use  of 
OPERATOR.  The  overhead  skeleton  program  repeats  the  statement: 

A = TRUE; 

to  obtain  a single  base  value  to  be  subtracted  from  all  tests.  Using  this 
base  value,  the  test  results,  therefore,  provide  a total  cost  which 
includes: 
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(1)  The  incremental  cost  of  evaluating  the  left  hand  expression 
as  opposed  to  evaluating  TRUE. 

(2)  The  invariant  cost  of  OPERATOR  . 

(3)  The  incremental  cost  of  the  interaction  between  the  left-hand 
expression  and  OPERATOR  . 

(4)  The  incremental  cost  of  the  interaction  between  OPERATOR 
and  the  right-hand  expression. 

(5)  The  cost  of  evaluating  the  right  hand  expression. 

To  obtain  these  costs  in  a wide  variety  of  environments  compile 
and  run  a series  of  tests,  using  each  of  the  follow  repetative  right -hand- 
side  forms: 


Variable  OPERATOR  TRUE. 

Variable  OPERATOR  FALSE. 

TRUE  OPERATOR  Variable. 

FALSE  OPERATOR  Variable. 

Variable  OPERATOR  Variable. 

Simple  Predicate  OPERATOR  TRUE. 

Simple  Predicate  OPERATOR  FALSE. 

TRUE  OPERATOR  Simple  Predicate. 

FALSE  OPERATOR  Simple  Predicate. 

Variable  OPERATOR  Simple  Predicate. 

Simple  Predicate  OPE  RATOR  Variable. 

Simple  Predicate  OPE.  .A TOR  Simple  Predicate. 
Compound  Expression  OPERATOR  TRUE. 

Compound  Expression  OPERATOR  FALSE. 

TRUE  OPERATOR  Compound  Expression. 

FALSE  OPERATOR  Compound  Expression. 

Compound  Expression  OPERATOR  Variable. 

Variable  OPERATOR  Compound  Expression. 

Compound  Expression  OPERATOR  Simple  Predicate. 
Simple  Predicate  OPERATOR  Compound  Expression, 
Compound  Expression  OPERATOR  Compound  Expression. 


where  "compound  expression"  includes  the  unary  and  binary  operator  forms. 
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For  each  "Variable",  use  the  forms 

• Variable  name  (real,  integer,  pointer,  etc.  where 
permissable  in  the  language). 

• AR  (I)  (all  types  of  arrays  and  subscript  forms). 

• COMP  (P)  (all  types  of  components  and  table  elements), 


Run  the  tests  for  static,  procedure  argument,  and  recursive  procedure 
argument  forms  for  "Variable". 

Argument  transmission  tests.  For  modular  software,  procedure 
argument  transmission  performance  is  an  important  consider'***-*  Jhis 
series  of  tests  examines  the  argument  transmission  performance  of  the 
compiler's  parsing  and  code  generr.  .on  raech^nitu*  , for  all  forms  of 
argument  transmission.  Argur »enr  accessing  is  not  considered  here; 
that  topic  is  covered  under  data  access  tests,  which  examines  all  forms 
of  data  references. 

The  forms  of  argument  transmission  considered  here  include  all 
forms  of  argument  permitted  in  a procedure  call  statement.  In  AED, 
this  statement  takes  the  form: 

F(argl,  arg2,  . . . , argn)  ; 

The  cost  associated  with  argument  transmission  includes: 

• The  cost  of  parsing  the  argument  list . 

• The  cost  of  generating  the  basic  argument  transmission 
cost  and  register  loading  instructions. 

• The  cos t of  accessing  the  value  of  each  argument. 

<*  The  co3t  of  creating  the  data  item  to  be  passed  for  each 

argument  and  placing  it  in  the  transmission  area. 

These  various  costs  are,  in  general,  inseparable,  and  the  tests  described 
below  make  no  attempt  to  separate  them.  The  technique  used  to  obtain 
performance  data  is  the  same  technique  used  with  other  language  features 
in  this  area:  a series  of  programs  is  constructed,  which  repeats  the 
language  feature  of  interest,  LOW  to  HIGH  timts.  A base  value  is 
subtracted  from  the  measured  cost  of  each  compilation  and  execution, 
to  eliminate  as  much  of  the  overhead  as  possible,  and  the  resulting  test 
data  is  plotted.  The  slope  of  the  resulting  graph  is  used  to  measure  the 
performance  of  the  feature  being  teeted. 
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The  base  value  for  the  argument  transmission  tests  is  obtained  by 
compiling  and  running  a test  program  of  the  form,  in  AED: 

BEGIN 

DEFINE  PROCEDURE  MAIN  TOBE 
BEGIN 


I 

r« 

f 


F(  ) ; 
F(  ) ; 


K 


K 


I 


F(  ) ; 

END; 

END  FIN  I 

This  test  therefore  represents  the  cost  of  passing  no  arguments,  but 
includes  the  calling  mechanism  and  other  overhead  costs. 

Tc  test  the  argument  transmission  feature,  construct  a series  of 
test  programs  which  repeat  the  statement: 

F(arg)  ; 

where  "arg"  is  set  to  the  following  forms,  one  at  a time: 

• Simple  variable  (integer,  real,  pointer,  procedure, 
label,  etc.  ) . 

• Structure  type  variations. 

AR(I)  (array,  for  I as  both  a literal  and  a variable 

and  using  from  one  to  the  highest  number  of  permissable 

subscripts). 

COMP(P)  (based  variable  (component  in  AED)). 

• Expression  "A  + B"  (if  this  form  is  available  in  the 
compiler) . 

Use  all  permissible  data  types  for  A,  B,  AR,  and  COMP.  For  the 
COMP(P)  form,  use  both  packed  and  unpacked  COMP  forms,  as  well 
as  positive  and  negative  offsets  from  P. 

It  is  anticipated  that  the  small  cost  of  parsing  an  argument  string 
(arg  1,  arg2, . . . ) versus  the  single  argument  form  discussed  above 
(f(arg))  is  only  of  academic  interest,  and  not  worth  the  effort  to  construct 
a separate  test  series.  That  is,  the  parsing  cost  of  processing  the 
comma  string  is  a very  small  portion  of  the  four  cost  items  discussed 
above.  „ „ 
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It  should  be  note  that  the  "expression"  form  (A+B)  is  the  simplest 
form  which  shows  the  cost  of  calculating  an  argument  value,  not  just 
accessing  a piece  of  data.  This  form  includes  additional  code  generator 
cost  during  compilation  and  during  execution  of  the  object  program,  and 
therefore  exercises  a portion  of  the  code  generator  not  tested  elsewhere 
(except  possibly  in  the  case  of  a packed  COMP  argument).  However, 
any  more  elaborate  forms  of  expression  merely  add  the  cost  of  expression 
evaluation,  and  are  not  directly  related  to  argument  transmission  costs. 


CHAPTER  10 

HOW  TO  EVALUATE  ENVIRONMENTAL  DIFFERENCES 

1 . How  the  Environment  Equalizing  Question  was  Studied 

Introduction.  In  Chapter  2 an  overview  was  presented  of  how  the 
environment  equalization  question  was  studied.  In  this  section,  this  topic 
will  be  discussed  in  further  detail.  For  convenience,  the  full  statement  of 
the  question  is  repeated  below. 

If  two  compilers  with  the  same  features  operate 
in  different  environments,  how  can  their  measured 
differences  in  performance  be  allocated  to  environ- 
mental differences  vs.  compiler  differences? 

The  main  thrust  of  the  approach  to  this  question  was  to  test  the 
feasibility  of  using  the  elements  of  a high  level  language  in  which  com- 
pilers are  written  as  a basis  for  establishing  a "compiler  Gibson  mix". 

The  investigation  was  very  limited  in  scope.  Static  and  dynamic  Compiler 
Demand  Profiles  were  constructed  from  the  AED  source  language  modules 
and  execution  behavior  of  two  compilers:  an  AED  compiler  and  a J3B 
compiler.  The  static  Compiler  Demand  Profiles  are  presented  in 
Chapter  11  and  the  dynamic  profiles  are  presented  in  Chapter  12.  Details 
of  the  methods  used  to  generate  these  profiles  will  be  presented  later  in 
this  section. 

Before  the  data  had  been  generated  from  which  the  profiles  were 
calculated,  it  had  been  expected  that  the  static  AED  and  J3B  profiles  might 
exhibit  differences  which  would  be  reduced  in  the  dynamic  profiles.  Had 
this  turned  out  to  be  the  case,  this  result  would  have  been  interpreted  as  a 
partial  demonstration  that  compilers  (perhaps  of  a specified  class)  all  have 
substantially  similar  dynamic  profiles,  and,  therefore,  a typical  profile 
can  be  established  which  would  be  used  to  define  the  desired  "compiler 
Gibson  mix".  The  results  of  the  study  produced  static  and  dynamic 
profiles,  both  of  which  established  an  overall  impression  of  great  similarity 
between  the  AED  and  J3B  profiles.  However,  the  static  profiles  showed 
significantly  greater  overall  similarity  than  the  dynamic  profiles.  From 
this  result  we  concluded  that  the  particular  method  used  to  generate  the 
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dynamic  profile  introduced  statistical  anomalies  for  reasons  discussed  in 
Chapter  12. 

The  principal  conclusion  drawn  from  the  overall  similarity  between 
the  profiles  of  the  AED  and  J3B  compilers  adequately  was  that  they  satisfied 
the  intended  partial  demonstration  that  compilers  are  essentially  similar 
with  respect  to  their  Compiler  Demand  Profiles,  and  that  a "compiler  Gibson 
mix"  cam  be  defined  on  the  basis  of  a suitably  established  "typical"  profile. 
The  profiles  presented  in  Chapters  11  and  12  are  used  in  Section  2 as  an 
illustration  of  such  a "typical"  profile,  and  a "compiler  Gibson  mix"  based 
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on  these  profiles  is  defined  as  an  example.  In  the  absence  of  better  data, 
based  on  a more  elaborate  study  than  the  present  one,  it  is  recommended 
that  the  example  "compiler  Gibson  mix"  defined  in  Section  2 be  used  as  a 
basis  for  "equalizing  environments"  until  better  data  becomes  available. 

Steps  used  to  generate  Compiler  Demand  Profiles.  The  steps 
listed  below  were  followed  in  generating  static  and  dynamic  Compiler 
Demand  Profiles  for  the  AED  and  J3B  compilers. 

1.  A list  of  AED  language  forms  were  prepared  which 
were  used  more-or-leas  as  a basis  for  the  profiles. 

This  list  was  approximately  a subset  of  the  list  of 
language  forms  for  a User  Profile  which  was  pre- 
sented in  Section  5 of  Chapter  8. 

An  AED  compiler  was  modified  to  collect  statistics 
on  the  occurrences  of  language  forms  in  the  modules 
being  compiled.  Due  to  the  nature  of  this  AED  com- 
piler, the  placement  of  the  instruments  was  most 
conveniently  made  in  such  a fashion  that  the  statistics 
were  actually  gathered  on  the  tree  structure  representa  - 
tion of  the  language  forms,  which  were  not  exactly 
isomorphic  with  the  forms  in  the  list  established 
during  Step  1.  Details  of  the  instrumentation  of  the 
AED  compiler  are  presented  in  Appendix  1. 

3.  All  AED  source  language  modules  of  an  AED  and 

J3B  compiler  were  compiled  using  the  instrumented 
AED  compiler  created  in  Step  2.  For  each  procedure 
of  each  module,  a table  was  printed  out  containing 
counts  of  occurrences  of  the  language  forms  found 
by  the  instrumented  compiler.  Appendix  3 presents 
samples  of  these  raw  data  tables,  together  with  an 
explanation  of  how  the  raw  data  is  interpreted. 

(Note  that  some  source  language  modules  of  the  two 
compilers  were  written  in  assembly  language,  and 
these  did  not  contribute  to  the  statistics.  Also,  AED 
library  routines  used  by  both  compilers  were  not 
included  in  the  statistics.  ) 
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4.  Two  J3B  source  language  programs  were  selected  from  a 
collection  of  such  programs  used  for  acceptance  testing  of 
the  J3B  compiler.  These  programs  in  combination  exhibited 
most  of  the  language  forms  in  the  list  generated  at  Step  1. 

The  programs  were  modified  so  that  two  corresponding  AED 
programs  could  be  prepared  which  were  as  syntactically 
identical  to  the  J3B  programs  as  we  could  make  them.  These 
four  test  programs  (two  AED  and  two  J3B)  are  presented  in 
Appendix  2. 

5.  Modified  version  of  both  the  AED  and  J3B  compilers  were 
created  which  would  count  the  number  of  calls  executed  to 
each  procedure  in  each  compiler. 

6.  The  modified  compilers  created  at  Step  5 were  used  to 
compile  the  corresponding  pairs  of  test  programs  produced 
at  Step  4.  The  results  of  these  compilations  were  counts 

of  the  number  of  times  each  procedure  of  each  compiler  was 
called  in  compiling  each  of  two  test  programs.  The  counts 
generated  from  the  pairs  of  test  programs  were  added 
together  to  create  weighting  factors  for  each  procedure  of 
each  compiler. 

7.  A program  was  written  which  would  combine  the  tables 
generated  at  Step  3 with  weighting  factors.  The  elements 
of  each  table  were  multiplied  by  the  weighting  factor  for  the 
table  (corresponding  to  a procedure).  Then  the  resulting 
tables  were  added  together  to  produce  a summary  table 

for  each  compiler.  This  program  was  used  twice  for  each 
compiler:  once  with  all  weighting  factors  set  to  1,  and  once 
using  the  weighting  factors  generated  at  Step  6.  The  resulting 
tables  constituted  the  raw  data  for  the  static  and  dynamic 
Compiler  Demand  Profiles  respectively. 

8.  The  tables  produced  at  Step  7 were  analyzed  manually  to 
produce  the  tables  and  bar  charts  which  represent  the  static 
and  dynamic  Compiler  Demand  Profiles  in  Chapters  11  and 
12  respectively. 

2 . How  to  Generate  a "Compiler  Gibson  Mix' ' 

Introduc tion.  In  this  section  a methodology  is  established  for 
defining  a "compiler  Gibson  mix"  trom  a typical  Compiler  Demand 
Profile.  This  methodology  is  illustra  ed  by  actually  defining  a "compiler 

I 

Gibson  mix"  in  terms  of  the  static  Compiler  Demand  Profiles  for  the 
AED  and  J3B  compilers  described  in  Chapter  11.  The  static  profiles 
were  used  rather  than  the  dynamic  profiles  because  the  AED  and  J3B 
static  profiles  v/ere  more  similar  than  were  the  corresponding  dynamic 
profiles.  (Possible  reasons  for  this  result  are  suggested  in  Chapter  12.) 
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The  form  the  "compiler  Gibson  mix"  takes  is  a system  of  AED 
statements  with  weights  specified  for  the  following  constituents: 

• Individual  statements. 

• Individual  statements  within  a category  or  sub-category  of 
statements. 

• Sub-categories  of  statements  within  a category  of  statements. 

• Categories  of  statements. 

• All  statements. 

The  choice  of  individual  statements,  sub-categories,  auid  categories  and 
the  weights  assigned  to  these  constituent  elements,  were  based  on  data 
presented  in  the  bar  graphs  of  Figures  15  through  26  in  Chapter  11. 


In  order  to  use  the  "compiler  Gibson  mix"  as  defined  in  this 
section,  each  constituent  element  must  be  assigned  a performance 
value  interpreted  as  the  execution  time  of  an  "average"  instance  of  the 
constituent  in  the  computer  environment  being  "equalized".  The  pro- 
cedures to  be  used  to  generate  actual  performance  timing  values  for 
individual  statements  are  discussed  in  Section  3.  How  these  values  are 
combined  with  the  assigned  weights  is  described  in  this  section.  Ultimately, 
the  result  of  this  calculation  of  weights  combined  with  values  yields  a 
performance  value  for  the  "all  statements"  constituent.  This  value  thus 
represents  the  following  single  characteristic  number  for  the  environ- 
ment: 

• The  execution  time  of  an  average  compiler  statement. 

Main  constituents  of  a "compiler  Gibson  mix".  Presented  below 
is  a list  of  main  categories  which  define  the  "compiler  Gibson  mix". 

For  these  main  categories  and  for  one  individual  statement,  a single 
underlined  letter  is  used  to  represent  the  measured  or  calculated 
performance  value  for  the  particular  constituent. 

• Z : all  statements. 

• A : assignment  statements. 

• C : procedure  calls. 

• G : GOTO  statements. 

• F : FOR  statements. 
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• Ij  IF  statements. 

• T : the  single  statement  X = 0;  (where  X represents  an 
integer  variable). 

The  categories  of  statements  xepresented  by  A,  C,  G,  F,  and  I_ 
will  be  defined  later  in  this  section.  Their  definitions  will  be  established 
in  such  a way  that  these  variables  will  represent  the  execution  time  of 
an  average  number  of  the  respective  category  plus  the  execution  time 
represented  by  T. 

These  categories  are  assigned  the  weights  appearing  as  coefficients 
in  the  following  equation: 

Z = .38  A + .25  C + .25  .1  + . 10  G + . 02  F * 1.00T  (1) 

The  weights  for  A,  C,  I_,  G,  and  F were  approximately  determined  from 
the  bargraph  of  Figure  15.  Note  that  the  J[  weight  is  a combination  of  the 
IF-THEN  and  IF -THEN --ELSE  frequencies.  The  weight  -1.  00  for  T is 
chosen  because  each  of  the  other  constituents  is  defined  to  include  a 
value  of  T,  and  in  combination  contribute  a combined  value  equal  to  the 
value  of  T. 

Thus,  the  variable  Z can  be  calculated  from  Equation  1,  provided 
values  can  be  assigned  to  each  of  the  six  variables  on  the  right  hand  side. 
However,  as  will  be  shown  below,  only  the  values  for  the  variables  A, 

C,  G and  T will  be  directly  derivable  from  values  for  individual  state- 
ments. The  variables^  and  F are  defined  in  terms  of  other  constituent 
categories,  including  the  category  represented  by  Z and_I.  J.  will  be 
calculated  by  Equation  2,  and  F will  be  calculated  by  Equation  3,  and  both 
of  these  equations  include  the  variables  Z and  on  the  right  hand  side. 
Thus,  to  arrive  at  a value  for  Z,  Equations  1,  2,  and  3 will  have  to  be 
solved  simultaneously. 

T : the  statement  X - 0.  The  assignment  of  values  to  individual 
statements  is  discussed  in  Section  3.  Thus  this  individual  statement  is 
assigned  a value  by  a method  described  in  that  section. 
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A : assignment  statements.  Assignment  statements  are  represented 
by  the  23  statements  listed  in  Table  1.  In  these  statements,  X,  Y,  Z, 
and  W all  represent  integer  variables.  For  each  statement  a weight  is 
presented.  The  sum  of  all  weights  is  800.  Thus,  the  value  of  the 
variable  A is  calculated  as  1/800  the  weighted  sum  of  the  values  of  the 
23  individual  statements.  The  assignment  of  values  to  individual  assign- 
ment statements  is  discussed  in  Section  3. 

The  assignment  of  weights  to  the  23  statements  were  based  on  the 
data  presented  in  the  bar  charts  of  Figures  19,  20,  and  23.  (The  literal 
17  was  arbitrarily  chosen  to  represent  a literal  other  than  1. ) Since  the 
data  did  not  separately  count  "+"  and  it  was  assumed  that  these 
operators  should  appear  equally.  The  operators  * and/were  excluded 
because  their  frequency  appeared  to  be  relatively  insignificant.  The 
statements  with  a single  operator  are  represented  two  ways: 

• X = X f (variable  or  literal). 

• X = Y ± (variable  or  literal). 

. Since  no  counts  were  available  to  distinguish  these  forms,  and  since  their 

values  might  be  significantly  different  on  some  computers,  equal  weights 
were  arbitrarily  assigned  to  them. 

One  further  observation  is  important  to  note.  The  weight  assigned 
i to  X = 0 includes  both  the  relative  weight  of  60  as  a constituent  representative 

of  all  assignment  statements,  but  also  an  additional  weight  of  400  so  that 
the  total  value  assigned  to  A includes  the  average  of  all  constituent 
assignments  plus  the  single  assignment  represented  by  the  variable  T. 

i 
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Table  1.  Weights  for  Assignment  Statements  in  "Compiler  Gib  sen  Mix" 


Assignment  Form  Weight 

X = 0 460 

X = 17  100 

X = Y 160 

X = X + 1 5 

X = Y + 1 5 

X = X - 1 5 

X = Y - 1 5 

X = X + Y 5 

X = Y + Z 5 

X = X - Y 5 

X = Y - Z 5 

X = X + 17  4 

X = Y + 17  4 

X = X - 17  4 

X = Y - 17  4 

X = (Y  + Z)  + 1 2 

X = (Y  - Z)  + 1 2 

X = (Y  + Z)  - 1 2 

X = (Y  - Z)  - 1 2 

X = (Y  + Z)  + W 4 

X = (Y  - Z)  + W 4 

X = (Y  + Z)  - W 4 

X = (Y  - Z)  - W 4 

TOTAL  800 


C : procedure  calls.  Procedure  calls  are  represented  by  the  6 
statements  listed  in  Table  2.  In  these  statements,  Y x,  Y2,  Y-j,  Y4, 
and  Y^  represent  integer  variables,  and  F represents  a procedure  name. 

It  is  assumed  that  procedure  F consists  of  the  single  executable  statement 
X = 0,  where  X is  an  integer  variable.  In  this  way,  the  single  execution 
of  any  of  the  6 statements  representing  the  procedure  call  category 
automatically  includes  execution  once  of  the  statement  represented  by 
the  variable  T, 

For  each  statement  in  Table  16,  a weight  is  presented.  The  sum 
of  all  weights  is  100.  Thus  the  value  of  the  variable  C is  calculated  as 
as  1/100  of  the  weighted  sum  of  the  values  of  the  6 individual  statements. 
The  assignment  of  values  to  individual  procedure  call  statements  is 
discussed  in  Section  3. 

The  assignment  of  weights  to  the  6 statements  was  based  on 
approximating  the  data  presented  in  the  bar  graph  of  Figure  25. 

Table  2.  Weights  for  Procedure  Calls  in  a "Compiler  Gibson  Mix" 


Procedure  Call  Form 

F ( ) 

F (Y  j) 

F (Yj,  Y2) 

F (Y x,  Y2,  Y3) 

F (Yx,  Y2,  Y3,  Y4) 

F (Yp  Y2,  Y3,  Y4,  Y5) 
TOTAL 


W eight 
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G : GOTO  statement.  The  GOTO  statement  category  is  represented 
by  the  single  statement  GOTO  labelname,  where  labelname  is  defined  as 
the  label  of  the  executable  statement  X = 0.  In  this  way,  the  value 
measured  for  the  GOTO  statement  will  also  include  the  execution  of  the 
statement  represented  by  the  variable  T,  The  assignment  of  values  to 
the  individual  GOTO  statement  is  discussed  in  Section  3. 

We  observe  that  in  principle  the  label  used  in  the  GOTO  statement 
could  be  local,  a switch,  or  a parameter  of  a procedure  (non-local  GOTO). 
However,  no  counts  are  available  to  distinguish  these  three  cases  in  the 
data.  Since  a spot  check  of  source  language  modules  showed  that  the 
local  label  .rase  was  by  far  the  most  common,  it  was  decided  to  ignore 
the  contributions  of  the  other  two  cases. 

F : FOR  statements.  The  FOR  statement  category  is  represented 
by  a single  example  combined  with  values  obtained  for  other  categories. 
The  8 ingle  FOR  statement  is: 

FOR  I = 1 STEP  1 UNTIL  10  DO  X = 0 

where  the  number  of  iterations,  10,  was  chosen  arbitrarily,  since  no 
data  was  available  on  the  number  of  times  FOR  loops  were  iteratively 
executed.  The  number  10  was  chosen  because  the  number  of  iterations 
was  thought  to  be  significantly  greater  than  1,  perhaps  one  order  of 
magnitude,  and  there  was  no  basiB  to  assume  that  it  might  be  as  much 
as  100  (i.  e.  two  orders  of  magnitude). 

Let  D represent  the  value  calculated  for  the  above  statement  by 
the  methods  described  in  Section  3.  We  then  calculate  F by  the  following 
equation. 

F = D - 9T  + 10  (.  58  B + , 02  C + . 20A  + . 201)  (2a) 

where  B represents  the  value  of  a BEGIN-END  block  of  statements 
following  "DO".  The  coefficients  of  B,  C,  A and  ^ approximate  the 
respective  non-zero  bars  of  both  AED  and  J3B  profiles  in  the  bar  chart 
of  Figure  18.  The  factor  10  in  the  equation  is  the  number  of  iterations 
spexified  for  the  FOR  loop.  The  term  - 9T  reduces  D by  the  proper 
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amount  so  that  F includes  in  its  value  a contribution  for  one  execution 
of  the  statement  corresponding  to  T. 

The  value  of  the  variable  B is  calculated  from  the  following 
equation: 

B = N X Z (2b) 

where  N represents  the  average  number  of  executable  statements  in  a 
BEGIN-END  block  following  "DO".  No  specific  data  was  available  on  the 
actual  distribution  of  statemen.c  categories  in  such  a BEGIN-END  block, 
and  it  was  arbitrarily  assumed  that  they  each  may  be  represented  by  the 
average  compiler  statement  with  a corresponding  value  of  Z.  N is 
calculated  from  the  equation: 

.58  N + .42  = 3.31  (2c) 

The  factor  . 58  and  the  term  .42  are  derived  from  the  same  considerations 
used  to  determine  the  coefficients  within  the  parentheses  of  Equation  2a. 
The  right  hand  side  of  3.  31  represents  the  average  number  of  executable 
statements  nested  in  FOR  loops,  as  determined  from  the  data  in  the  bar 
graphs  of  figures  13  and  14.  to  is  found  to  be  4.  8.  Combining  this 
result  and  Equations  2a  and  2b  yield  the  following  single  equation  for 
evaluating  the  variable  F: 

F=D  -9T+19Zr.2C  + 2A  + 2I  (2) 

Note  that  in  this  equation,  the  only  right  hand  side  variables  not  directly 
derived  from  combinations  of  values  for  single  statements  are  Z and  J.. 

I : IF  statements.  The  IF  statement  category  is  represented  by 
two  sub-categories: 

• IF  expression  THEN  U = 0 

• IF  expression  THEN  U = 0 ELSE  V = 0 


where  U and  V are  integer  variables 


Let  the  variables and  represent  the  values  calculated  for 
these  two  sub-categories  respectively.  Then,  the  value  for  the  variable 
I is  calculated  from  the  following  equation: 

I_s.75  (Ijt.  48B  + . 16C  + . 16G  + . 16A  + . 04T)  (3a) 

+ . 25  (I2  + . 28B  + . 12C  + . 04G  + . 20A  + . 36l)  - . 67T 

where  B is  interpreted  as  in  Equations  2a  and  2b.  This  interpretation  of 
B assumes  that  the  BEGIN-END  block  following  "THEN"  and  "ELSE" 
contain  the  same  average  distribution  of  constituents  as  the  BEGIN-END 
block  following  "DO".  This  assumption  is  made  arbitrarily  in  the 
absence  of  any  better  data  on  the  structures  of  BEGIN-END  blocks  in 
different  contexts.  The  coefficients  . 75  and  . 25  are  derived  from  the 
data  for  the  IF-THEN  bars  and  ELSE  bars  in  the  bar  chart  of  Figure  15. 
The  coefficients  in  the  parentheses  were  derived  from  approximations 
of  the  data  in  Figures  16  and  17.  The  term  -.67T  is  included  to  subtract 
off  the  net  contribution  for  the  statement  X = 0 contained  in  the  values 
of  the  variables  C,  G,  A and  L 

Combining  the  value  for  N of  4.  8 with  Equations  2a,  2b,  and  la, 
and  simplifying,  the  following  equation  results: 

1 = . 75_I1  + . 25  J. £ - .67T  + . 15C  + . 13G  + . 17A  + . 121  + 1.  26Z  (3) 

Note  that  in  this  equation  the  only  right  hand  side  variables  noc  directly 
derivable  from  combinations  of  values  for  single  statements  are  Z and 

The  single  statements  that  comprise  the  two  sub -categories  are 
formed  by  using  one  of  the  17  Boolean  expressions  listed  below  in 
Table  3.  For  each  Boolean  expression  a weight  is  given,  which 
represents  the  weight  to  be  assigned  the  IF  statement  in  either  sub- 
category using  that  Boolean  expression.  The  sum  of  all  the  weights  is 
200.  Thus  each  oi  the  two  variables  jtj  andj^  i*  calculated  as  1/200  of 
the  weighted  sum  of  the  values  assigned  to  the  17  individual  statements 
comprising  their  respective  sub-categories. 
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Table  3.  Weights  for  Boolean  Expressions  In  IF 
Statements  in  a "Compiler  Gibson  Mix" 


Form  of  Boolean  Expression 
Used  in  an  IF  Statement 


Weight 


X ==  Y 
X «i*Y 
X ==  0 
X -,=  0 
X ==  17 


X ==  Y OR  Z ==  W 
X ==  Y OR  Z -,=  W 
X -,  = Y OR  Z ==  W 
X -i  = Y OR  Z = W 
X ==  Y AND  Zf=W 
X ==  Y AND  Z -,  = W 
X -i  = Y AND  Z ==  W 
X = Y AND  Z = W 
X + Y - 17 
X - Y = 1? 


TOTAL 


In  Table  3,  B represents  a Boolean  variable,  and  X,  Y,  Z,  and  W 
represent  integer  variables.  Weights  assigned  to  each  Boolean  expression 
are  based  on  approximations  of  the  data  in  the  bar  charts  of  Figures  21 
and  22. 

The  assignment  of  values  to  fjadividual  IF  statements  is  discussed 
in  Section  3.  Note  that  in  Table  3,  the  literal  17  is  used  to  represent 
an  arbitrary  literal  other  than  0. 
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3.  How  to  Equalize  Environments 

Overview.  In  this  section  a discussion  is  presented  on  how  a 
"compiler  Gibson  mix"  (such  as  the  one  defined  as  an  example  in 
Section  2)  might  be  used  to  "equalize"  environments.  We  note  that  the 
"compiler  Gibson  mix"  of  Section  2 is  based  on  65  individual  statements 
in  the  following  categories: 


t 


! 
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• 23  assignment  statements  (including  the  special  statement 
X = 0 alone  comprising  a main  category). 

• 6 procedure  CALL  statements. 

• 1 GOTO  statement. 

• 1 FOR  statement. 

• 17  IF  statements  without  an  ELSE  clause. 

• 17  IF  statements  with  an  ELSE  clause. 

A procedure  will  be  described  below  for  assigning  a performance 
value  to  a statement  which  is  applicable  to  all  65  statements.  The  per- 
formance value  will  represent  the  CPU  time  required  by  a particular 
computer /operating  system  environment  to  execute  the  functionality 
represented  by  the  statement.  The  65  values  derived,  one  for  each 
statement,  may  then  be  combined  in  the  manner  described  in  Section  2 
to  arrive  at  a value  for  the  variable  Z.  This  derived  value  for  Z will 
represent  the  CPU  time  required  by  the  computer /operating  system 
environment  to  execute  the  functionality  represented  by  an  "average" 
AED  statement  used  in  writing  a compiler  in  the  AED  language. 

Let  us  suppose  that  a series  of  test  programs  (as  described  in 
Chapter  9)  have  been  compiled  with  compiler  1 in  computer  /operating 
system  environment  E^,  and  the  same  test  programs  are  compiled  with 
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compiler  2 in  environment  "E,^,  Let  us  suppose  further  that  the  compiler 
execution  times  of  these  test  compilations  have  been  measured,  and  that 
the  results  have  been  organized  into  two  Compiler  Performance  Profiles, 
say  and  respectively,  using  the  methods  described  in  Chapter  8. 

Then,  the  two  Compiler  Performance  Profiles  can  be  normalized  for 
thoir  respective  environments  (i.  e.  their  environments  can  be  "equalized") 
by  dividing  each  component  of  P^  by  the  Z value  derived  for  environment 
Ej,  and  dividing  each  component  of  Pjj  by  the  Z value  derived  for  environ- 
ment E 2*  The  resulting  normalized  profiles  now  reflect  the  performance 
of  the  compiler  in  a "standard"  environment. 

We  note  that  the  procedure  described  above  "equalizes"  environments 
with  respect  to  processor  speed,  instruction  set  (see  below),  and  one 


8 


i 

r 


\ 


aspect  of  operating  system  support  (see  below).  However,  no  account 
has  been  taken  of  differences  in  memory  size.  In  the  course  of  this  study 
it  became  clear  that  the  performance  of  compilers  on  similar  computers 
with  different  memory  sizes  was  in  general  very  complex,  and  would 
require  as  much  additional  study  as  that  undertaken  in  the  present  study 
for  • equalizing"  what  is  primarily  processor  speed  and  instruction  set. 

The  investigation  did  suggest  the  following  observations: 

• A one-pass  compiler  either  fits  in  core  or  it  does  not.  If  it 
does,  then  the  available  core  not  occupied  by  the  compiler 
code  and  fixed  data  structures  will  place  a .'imit  or.  the 
size  oi  program  that  can  be  compiled.  There  are  no  other 
performance  trade-off  considerations  for  a one-pa<s  compiler. 

• A multi-pass  compiler,  such  as  that  described  in  Section  4 
of  Chapter  3,  can  be  organized  to  operate  in  a minimum 
quantity  of  core,  by  using  a relatively  large  number  of 
phases.  In  such  an  environment,  the  throughput  of  a. 
compilation  will  depend  on  the  I/O  channel  and  device 
operational  time  used  for  overlays  in  addition  to  CPU 
time. 

• It  is  theoretically  possible  to  balance  the  space /time  trade 
off  in  architecting  a multi-pass  compiler  in  fewer  phases 
that  are  used  in  the  architecture  of  Section  4 of  Chapter  3. 

Instruction  set  differences  are  taken  into  account  by  the  method 
in  which  performance  values  are  assigned  to  individual  statements. 
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This  method  is  discussed  below.  The  one  aspect  of  operating  system 
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support  taken  into  account  is  the  mechanism  used  for  a standard  calling 
sequence  interface  in  procedure  or  function  calls.  Other  aspects  of 
operating  system  support  will  be  discussed  briefly  in  Section  4. 

Assigning  values  to  statements.  The  following  method  can  be 
used  to  assign  a performance  value  to  a statement  which  will  represent 
the  CPU  time  required  in  a particular  environment  for  executing  the 
functionality  represented  by  the  statement.  This  method  is  applicable 
to  all  65  statements  listed  above.  However,  certain  special  considera- 
tions are  important  to  take  into  account  for  IF,  GOTO,  and  call  statements. 
These  special  considerations  are  discussed  later  in  this  section. 

First  choose  two  integers  n and  m,  (say  m > n)  which  will  be 
used  in  the  manner  described  below.  Then  have  a good  coder  code  the 
functionality  represented  in  the  statement  in  assembly  language  as 
efficiently  as  he  possibly  can.  This  use  of  a good  coder  and  assembly 
language  will  enable  the  functionality  to  be  executed  using  the  full  power 
of  the  available  instruction  set,  thereby  "equalizing"  for  instruction 
set  as  well  as  for  processor  speed.  Next  two  assembly  programs  are 
produced  which  are  identical  except  for  the  inclusion  in  one  of  n replications 
of  the  coding  for  the  statement,  and  in  the  other  of  m replications  of  this 
coding.  (If  labels  appear  in  the  coding,  then  new  labels  will  of  course 
have  to  be  introduced  for  each  replication. ) These  assembly  language 
programs  will  include  whatever  declarations  and  initializations  of 
variable  used  that  are  required,  and  whatever  other  special  assembly 
language  elements  are  required  to  create  programs  that  will  assemble 
executable  object  code. 

It  is  obvious  that  the  difference  in  execution  times  of  the  two 
programs  will  reflect  m-n  executions  of  the  statement.  Therefore  1/ 

(H}-H)  this  difference  is  the  performance  value  to  be  assigned  to  the 
statement.  In  order  to  get  meaningful  time  measurements,  m and  n must 
be  sufficiently  large,  and  m must  be  sufficiently  larger  than  n,  for  the 
granularity  of  the  clock  used  in  the  measurements  to  be  insignificant. 
Generally  m should  be  at  least  2 n,  and  probably  3 n to  10  n would  be 
better.  The  reason  two  runs  are  used,  one  each  for  n and  m replications, 
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rather  than  a single  run  to  eliminate  any  overhead  appearing  in  the 
program  for  such  functions  as  1\ -cation  of  work  space,  initialization, 
etc. 

IF  statements.  In  «...  signing  values  to  IF  statements,  several 
different  pairs  of  runs  should  be  made  for  each  statement.  Each  of  the 
pairs  of  runs  (having  n and  m replications)  would  use  different  combina- 
tions  of  initializations  for  the  variables  B,  X,  Y,  Z and  W.  Since  no 
data  is  available  as  to  the  relative  frequency,  the  Boolean  expressions  in 
IF  statements  evaluated  to  TRUE  or  FLASE,  arbitrarily  the  combinations 
of  initializations  should  be  such  that  TRUE  and  FALSE  evaluations 
occur  equally  often.  The  value  assigned  to  an  IF  statement  would  be 
derived  from  the  average  of  the  values  for  each  pair  of  runs. 

GOTO  statements.  In  order  to  avoid  possible  peculiar  execution 
patterns  resulting  from  the  chaining  of  GOTO  statements,  each  GOTO 
statement  should  specify  a label  of  a statement  of  the  form  X = 0,  as 
follows: 

GOTO  labelname; 

labelname:  X = 0;  . 

It  is  the  assembly  language  code  for  this  pair  of  statements  that 
is  replicated  n and  m times.  Then  the  value  assigned  to  the  GOTO 
statement  is  calculated  as: 

G = (l/(m-n))  (tjn  - tn) 

where  t and  tn  represent  the  measured  execution  times  for  the  programs 
with  m and  n replications,  respectively.  This  definition  includes  the  time 
to  execute  the  statement  corresponding  to  T^  in  the  valuation  of  G. 

CALL  statements.  In  coding  the  call  statements,  the  coder  must 
take  the  following  considerations  into  account. 

e If  a convention  is  established  for  calling  sequences  in 
procedure  and  function  calls  which  is  to  be  followed  by 
the  object  code  of  a compiler  operating  in  the  environment 
being  "equalized"  then  this  convention  must  be  followed 
in  coding  the  six  CALL  statements  listed  in  Section  2. 
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• For  each  CALL  statement,  a separate  program  must  be 
coded.  This  program  will  consist  of  an  assembly  language 
version  of  a procedure  with  the  appropriate  number  of 
arguments,  following  all  established  conventions  for 
parameter  passing,  and  consisting  of  the  assembly  language 
version  of  the  single  executable  statement  X = 0.  Each 
occurrence  of  the  procedure  call  in  the  pair  of  test 
programs  (with  n and  m replications  of  the  procedure  call) 
will  be  a call  to  the  special  assembly  language  procedure 
described  above, 

4.  Timing  Data  and  "Equalising"  Environments 

Introduction.  In  addition  to  the  development  of  static  and  dynamic 
Compiler  Demand  Profiles,  as  described  in  Chapters  11  and  12  and 
generated  as  described  in  Section  1,  a parallel  activity  was  followed  to 
explore  the  possibility  of  establishing  timing  data  as  components  of 
dynamic  profiles.  The  results  of  this  parallel  activity  were  such  that 
no  useful  timing  comparisons  were  possible  between  the  AED  and  T^B 
compilers,  since  certain  bottleneck  routines  in  the  AED  support  library 
(used  by  both  compilers)  had  been  rewritten  for  J3B  to  be  more  efficient. 
The  procedure  followed  in  collecting  the  timing  data  is  described  below, 
and  a few  interesting  observations  on  the  resulting  data  are  summarized 
at  the  end  of  this  section. 

Collecting  timing  data.  One  test  program  was  compiled  by 
modified  versions  of  the  AED  and  J3B  compilers.  These  modified 
compilers  used  the  computer's  13  microsecond  clock  to  measure  the 
total  time  spent  in  each  procedure  of  the  compilers  and  library  routines 
used  by  the  compilers.  The  test  program  was  the  smaller  of  the  two 
programs  "sed  to  generate  dynamic  Compiler  Demand  Profiles  as 
described  in  Chapter  12.  The  listings  of  these  test  programs  are 
included  with  Appendix  2 of  this  report. 

The  timing  measurements  were  output  to  a file  which  were 
processed  by  a separate  program  to  produce  a suitably  formatted  report. 

Interpreting  the  timing  data.  The  reports  generated  in  the  manner 
described  above  were  further  analyzed  by  hand  calculations.  The 
following  interesting  patterns  were  found. 
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• Input  and  output  related  CPTJ  processing  of  characters 
occupied  about  40%  of  the  total  CPU  time  used  to  compile 
the  test  program  by  both  the  /.  and  J3B  compilers.  In 
the  AED  compiler,  this  broke  ,.<own  as  20%  input  and  20% 
output;  in  J3B,  it  was  15%  input  and  25%  output. 

• Dynamic  core  management  used  an  additional  20%  of  the 
CPU  time  in  AED,  and  15%  of  the  time  in  J3B. 

e Intermediate  input/output  between  compiler  passes  used 
only  2-3%  of  the  total  time. 

Included  in  input/output  of  characters  is  time  spent  in  conversion  between 
internal  and  external  formats  and  chara  :ter  transmission  codes,  as  well  as 
buffer  management,  etc.  It  was  discovered  that  the  reduced  time  for 
input  in  J3B  was  due  to  the  rewriting  for  J3B  of  the  library  routines 
used  to  perform  thsse  functions  in  the  AED  compiler.  The  high  fraction 
of  time  for  output  in  J3B  was  due  to  an  increased  quantity  of  output 
generated  by  this  compiler,  including  set/used  listings,  environment 
listings,  etc. , which  are  not  output  by  the  AED  compiler. 

Due  to  the  significant  rework  of  several  support  functions  for 
J3B  for  compiler  efficiency,  it  was  therefore  determined  that  the  above 
data  was  not  useful  for  "equalizing"  environments  considerations.  How- 
ever, the  large  amounts  of  time  spent  in  character  input /output,  the 
significant  savings  that  can  be  accomplished  by  using  specially 
programmed  support  subroutines  in  these  areas,  and  the  relatively 
small  time  spent  in  intermediate  (between  passes)  input/output,  should 
be  of  interest  to  compiler  designers  and  implementors.  In  this  light, 
it  should  also  be  noted  that  the  time  spent  in  dynamic  core  management 
could  be  significantly  less  in  a compiler  with  a fixed  core  utilization 
scheme,  but  this  type  of  design  leads  to  a large,  fixed  sized,  rigid 
compiler. 

Cne  final  observation  is  relevant  heie.  Since  there  appears  to  be 
a significant  function  of  time  spent  performing  these  functions,  further 
study  appears  to  be  desireable  to  determine  how  differences  in  the 
operating  system  support  of  character  string  I/O  and  dynamic  core 
management  miQht  be  "equalized"  between  environments. 
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CHAPTER  11 

STATIC  COMPILER  DEMAND  PROFILE  DATA 
1.  Overview 

This  chapter  presents  all  static  data  gathered  from  the  AED  and 
JOVIAi_./J3B  compilers.  The  next  chapter  entitled  "Dynamic  Compiler 
Demand  Profile  Data"  (Chapter  12)  contains  a parallel  set  of  data  in 
which  dynamic  weighting  factors  are  applied  to  the  static  information. 

The  two  chapters  taken  together  present  a summary  of  all  non-timing 
data  gathered  during  the  project. 

The  information  is  grouped  into  three  major  sections  as  follows: 

• Tables  of  the  AED  and  J3B  compilers'  usage  of  AED 
language  forms. 

e Bar  chart  representations  of  various  histograms  of 
usage  patterns. 

• Bar  chart  of  the  relative  percentage  of  usage  of  various 
AED  language  forms. 

Each  of  the  tables  presents  a logical  group  of  data  about  the 
types  of  and  form  of  AED  statements  used  in  the  two  compilers.  Numbers 
presented  in  the  tables  were  derived  by  compiling  each  individual  source 
program  module  of  each  compiler  through  a special  "instrumented1'  AED 
compiler  which  tested  for  certain  predefined  language  constructs  and 
which  generated  output  totals  for  each  mo.-ule.  A second,  summation 
program  was  later  run  on  these  sub-totals  to  calculate  grand  totals 
for  each  of  *-he  two  compilers.  (The  details  cf  the  data  collection  and 
reduction  methods  used  a. presented  in  Appendix  1 / Each  compiler 
contains  about  450  procedures,  with  J3B  being  the  larger  of  the  two. 
Library  support  routines  are  not  included  in  the  statistics. 

Each  of  the  tables  presents  the  number  of  occurrences  of  various 
statement  and  clause  types  in  the  context  of  other  statement  and  clause 
types.  In  addition,  the  number  of  occurrences  of  various  arithmetic 
and  Boolean  operators,  and  various  forms  of  arithmetic  and  Boolean 
expressions  are  also  presented.  The  following  is  a list  of  the  subjects 
of  the  tables  presented  in  Section  2. 
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• Statement  types  and  total  arithmetic  and  Boolean  operators 
and  labels. 

• Assignment  statement  forms, 

• Forms  of  statements  used  with  conditionals  and  loops. 

• Form_  of  loop  statement  clauses. 

• Forms  of  integers  used  in  loops. 

• Forms  of  arithmetic  phrases. 

• Forms  of  Boolean  phrases. 
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The  bar  chart  histograms  of  usage  patterns  are  presented  in 
Section  3.  They  consist  of  a series  of  histograms  showing  the  number 
of  occurrances  in  the  compiler  of  a particular  AED  language  form 
having  n occurrences  of  a particular  constituent  component.  The  follow- 
ing is  a list  of  the  forms  and  constituents  for  the  histograms: 

• Number  ol  procedure  calls  having  n arguments. 

® Number  of  assignment  statemerts  having  n R.H.S, 
(right-aund-side)  operators. 

• Number  of  boolean  expressions  in  IF  clauses  containing  n 
operators. 

• Number  of  FOR  statements  nested  n deep. 

• Number  of  executable  statement  s nested  n r'.eep 
in  FOR  loops. 

In  Section  4,  the  relative  percentage  bar  charts  are  presented. 
These  bar  charts  shew  the  relative  percentage  of  occurrences  of 
various  statement  and  clause  types,  alone  and  in  specified  contexts. 

In  particular,  histograms  are  presented  which  show  the  percentage  of 
occurrences  of  a statement  or  clause  type  with  n occurrences  of  a 
specific  constuent  component.  The  following  i.s  r.  list  of  the  subjects 
of  the  bar  charts  presented  In  Section  4. 

• % of  Use  of  Statement  Types. 

• % of  Statement  Types  used  following  'THEN'. 

• % of  Statement  Types  used  following  'ELSE'. 

• % of  Statement  Types  used  following  'DO'. 

• % of  Use  of  Arithmetic  Operators. 

• % of  Use  of  Arithmetic  Forms. 
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Table  4.  Summary  of  Static  Usage  of  Statement  Types 
Operators,  and  Labels 
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Boolean  forms  following  an  "IF",  and  not  those  forms  used  in  Boolean 
assignment  statements  (e.g.  "BOOL1  = BOOL2  AND  BOOL3").  However, 
the  great  majority  of  the  use  of  Boolean  operators  do  follow  an  "IF", 
and  the  count  presented  should  be  quite  close  to  the  actual  total. 

It  is  evident  from  the  numbers  presented  that  the  two  compilers 
are  remarkably  close  in  all  categories  shown.  Assignment  statements 
and  call  statements  are  the  most  heavily  used  statement  type,  whereas 
looping  ("FOR")  statements  are  rarely  used  as  compared  with  the 
conditional  ("IF")  forms.  Also,  arithmetic  operations  are  used  much 
less  frequently  than  Boolean  operations.  This  is  to  be  expected  with  a 
"system  program"  such  as  a compiler.  In  scientific  and  engineering 
applications,  on  the  other  hand,  Knuth  has  found  that  among  a large 
number  of  FORTRAN  programs,  arithmetic  forms  are  much  more 
common  than  Boolean  forms. 

Assignment  statement  forms.  Table  5 summarizes  the  static 
usages  of  selected  sub-categories  cf  a:  signment  statements.  It  is 
particularly  interesting  to  note  the  extremely  heavy  use  of  the  form 
"A  = B"  an  compared  to  all  other  forms.  It  should  be  noted  that  this 
sub-category  includes  all  combinations  of  such  constructions  as 
1 'COMP  1 (PTR)  = COMP 2 (PTR)",  "COMP 3 (PTR)  = X"  etc.  These 
constructions  are  heavily  used  in  both  the  AED  and  J3B  compilers  for 
manipulating  the  compiler's  data  structures.  However,  even  in  compilers 
without  this  pointer  structure,  capability,  the  simple  assignment 
category  is  expected  to  be  very  heavily  used.  In  general,  the  profile 
of  usage  by  sub-categories  is  remarkably  similar  between  the  two 
compilers. 

Statement  types  used  with  conditionals  and  loops.  Tabio  6 presents 
a summary  of  the  static  usages  of  five  statement  types  (BEGIN, 
procedure  call,  FOR,  IF,  GOTO,  assignment)  in  the  three  contexts 
immediately  following  the  three  AED  keywords:  THEN,  ELSE,  and  DC. 

THEN  and  ELSE  are,  of  course,  keywords  which  begin  conditionally 
executed  clauses;  DO  establishes  the  iterative  loop  of  a FOR  statement. 
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The  numbers  presented  in  Table  6 again  show  the  high  degree 
of  profile  similarity  between  the  AED  and  J3B  compilers.  The  following 
is  a list  of  observable  attributes  of  the  two  profiles: 

• Compound  statements  (BEGIN)  most  frequently  follow 
THEN  and  DO  in  both  profiles. 

• The  form  ELSE  IF  shows  significant  prominence.  It 
exceeds  the  number  of  occurrences  of  BEGIN  in  J3B 
(165/78)  and  approximates  the  BEGIN' s in  AED 
(109/130).  This  suggests  the  general  popularity  of 
using  chains  of  IF  - THEN  - ELSE  - IF  combinations 
to  express  complex  conditions.  In  comparison,  the 
IF  - THEN  - IF  form  is  used  much  less  frequently, 
s>  ^gesting  that  Boolean  phrases  (e.g.  BOOL1  AND 
BOGL2  OR  BOOL3)  are  commonly  used  to  select 
the  precise  THEN  condition  when  needed. 

e Little  if  any  use  is  made  of  loops  (FOR)  following 

THEN  ELSE  or  DO,  although  they  may  be  hidden  from 
our  statistics  by  being  written  within  BEGIN  - END 
blocks. 

FOR  statement  sub-types.  Table  7 presents  the  number  of 
occurrer-ies  of  each  of  the  following  four  sub-types  of  FOR  statements: 

• Using  UNTIL  clauses. 

• Using  WHILE  clauses. 

• Using  multiple  iteration  lists. 

• Other. 

The  AED  and  J3B  profiles  are  again  seen  to  very  similar.  Note 
that  the  UNTIL  clause,  which  tests  for  a specific  numeric  value  of  the 
index  variable,  is  the  most  popular  form,  even  though  the  more  general 
WHILE  clavj.se  could  be  used  to  handle  all  UNTIL  conditions,  although 
with  slightly  more  work  by  the  user.  Multiple  iteration  lists  come  in 
a poor  tnird,  showing  that  loops  are  seldom  controlled  by  lists  of 
multiple  conditions. 

Integer  forms  in  FOR  statements.  Table  8 presents  the  number 
of  occurrences  of  four  forms  that  are  used  in  each  of  three  integer 
variable  (or  expression)  positions  that  occur  in  FOR  statement  con- 
structions. The  four  integer  forms  are: 
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• The  literal  1. 

• Literals  other  than  1. 

• An  integer  variable  (represented  as  "A"). 

• Integer  expressions. 

The  three  contexts  with  FOR  statements  in  which  the  integer  forms  occur 
are  the  following: 

• Left  of  STEP.  This  context  specifies  the  first  value  of 
the  index  variable  to  be  used  in  the  loop. 

• Right  of  STEP.  This  context  specifies  the  increment 
(assumed  positive)  which  is  added  to  the  index  variable 
for  each  successive  iteration  of  the  loop. 

• After  UNTIL.  This  specifies  the  limit  value  of  the 
index  value  used  in  the  loop.  (Note  that  a GREATER 
THAN  test  is  made,  and  this  limit  value  might  be 
exceeded  by  the  last  increasing  of  the  index  value. 

Thus  the  limit  value  might  not  be  used  in  the  loop. 

Here,  the  AED  and  J3B  profiles  show  some  clear  differences, 
although  there  is  also  evident  significant  similarities.  In  J3B,  the 
initial  value  of  the  index  variable  is  most  commonly  a literal  not  equal 
to  1 (25/6),  while  in  AED  the  split  between  1 and  other  literals  is  even 
(18/18).  In  both  compilers,  the  incrementing  value  (RIGHT  OF  STEP) 
is  almost  always  1.  The  terminating  test  value  (AFTER  UNTIL)  is 
usually  a variable  (16  in  J3B,  20  in  AED).  For  the  second  most 
common  form  AFTER  UNTIL,  an  expression  (10),  while  AED  makes 
more  use  of  a literal  (14). 

Arithmetic  forms.  TabJe  9 presents  the  number  of  occurrences 
of  ten  ai  chmetic  forms  that  appear  in  arithmetic  expressions.  Each 
form  involves  one  of  the  following  three  groups  of  operators: 

• + (plus)  or  - (minus), 

• * (multipled  by),  or 

• / (divided  by). 

The  ten  arithmetic  forms  are  listed  below.  In  these  forms,  "A"  and 

i 

! "B"  denote  arithmetic  variables.  In  collecting  the  data,  the  actual 

I data  type  of  the  variables  were  ignored.  However,  in  spot  checking 
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the  source  language  programs  we' found  only  integers  used  in  arithmetic 
forms.  The  ten  forms  are: 

(1)  A operator  specific  literal  (1  or  2).  The  particular  literal 
depends  upon  the  operator  used  in  the  form:  1 is  used  with 
+ and  2 is  used  with  * and  /. 

(2)  Specific  literal  (1  or  2)  operator  A.  Here  1 is  used 

wuh.  and  /;  2 is  used  with  *. 

(3)  A operator  literal  other  tb.^n  the  specific  literal  used 
in  (1)  above. 


* 

i 


(4)  Literal  (other  than  that  usee’  in  (2)  above)  operator  A. 

(5)  A operator  3. 

(6)  Arithmetic  expression  operator  specific  literal  (1  or  2). 
The  literal  values  are  as  in  (1)  above. 

(7)  Specific  literal  (1  or  2)  operator  arithmetic  expression. 
The  literal  values  are  as  in  (2)  above. 


(8)  Arithmetic  expression  operator  literal  other  than  that 
used  in  (6)  above. 

(9)  Literal  (other  than  that  used  in  (7)  above)  operator 
arithmetic  expression. 

(10)  Other  forms  than  the  above. 


The  following  three  specific  forms  are  seen  to  be  by  far  the  most 
frequently  used: 

• Ail, 

• A i literal  other  than  1,  and 

• A i B. 

The  inverse  form  of  the  last  two  (1  + A or  other  literal  +A)  are 
rarely  used,  indicating  that  most  programmers  write  expressions  of 
the  form  "A  f 1"  and  A ± n rather  than  "If  A"  and  n ± A even  though 
both  forms  are  logically  equivalent. 

The  fourth  most  frequently  used  form  is  the  "OTHER"  uses  of 
the  + operator.  The  "OTHER"  form  includes  all  forms  not  specified  in 
forms  (1)  through  (10).  However,  probably  the  form  most  frequently 
used  in  this  category  is: 

© Arithmetic  expression  operator  arithmetic  expression 
(e.g.  (A+B)  * (C+D). ) 
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The  form  EXPRESSION  i 1 also  receives  high  usage,  although  usage  of 
the  form  literal  (other  than  1)  i A exceeds  this  in  the  J3B  compiler. 

Note  also  that  * and  / are  rarely  used  as  compares  with  + or  -.  This 
is  to  be  expected  in  system  programs  in  contrast  with  scientific  or 
engineering  programs. 

Overall,  is  again  evident  that  the  AED  and  J3B  profiles  are 
very  similar. 

Boolean  forms.  Table  10  prefer.! « the  number  of  occurrences  of 
ton  Boolean  forms  that  appear  in  Boolean  expressions  within  IF  state- 
ments. Each  form  involves  one  of  the  following  four  groups  of  predicates 
or  the  Boolean  connectives  AND  or  OR: 

• Equals  (=  =). 

.»  Greater  than,  or  not  less  than  {>  or  >=). 

• Less  than,  or  net  greater  thrji  (<  or  <=). 

• Not  equal  ( -i  =). 

The  ten  Boolean  forms  are  listed  below.  In  these  form  a,  "A"  and  "B" 
denote  variables.  Spot  checking  of  the  use  of  variables  with  predicates 
found  no  examples  other  than  arithmetic  integer  data  types.  When 
used  with  a Boolean  connective,  AND  or  OR,  "A"  and  "B"  denote  Boolean 
variables.  Forms  (1),  (2),  (6)  and  (7)  are  not  applicable  to  the  AND 
and  OR  connectives.  The  ten  forms  are: 

(1)  Variable  predicate  C. 

(2)  0 predicate  variable. 

(3)  Variable  predicate  ilteral  other  tban  0,  or  Boolean 
vasri^oie  predicate  Boolean  liteval  (TRUE  or  FALSE). 

(4)  Literal  (other  than  0)  predicate  variable,  or  Boolean 
literal  (TRUE  or  FALSE)  predicate  Boolean  variable. 

(5)  Variable  predicate  variable,  or  Boolean  variable 
connective  (AND  or  OR)  Boolean  variable. 

(6)  Expression  predicate  0. 

(7)  0 predicate  expression. 

(8)  Expression  predicate  literal  other  than  0,  or  Boolean 
expression  connective  (AND  or  OR)  Boolean  literal 
(TRUE  or  FALSE). 
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(9)  Literal  (other  than  0)  predicate  expression,  or  Boolean 
literal  (TRUE  or  FALSE)  connective  (AND  or  OR) 

Boolean  expression. 

(10)  Other  forms  than  the  above. 

Forms  (1),  (3)  and  (5),  especially  using  the  predicate  =-  are 
seen  to  be  by  far  the  most  frequently  used.  However,  J3B  appears  to 
use  the  form  A ==  literal  (other  than  0)  much  more  frequently  than 
A ==  0 or  A ==  B,  and  AED  uses  these  three  forms  in  roughly  the  same 
numbers.  These  results  again  indicate  a stylistic  preference  for  the 
form  A -=  0 rather  than  the  functionally  equivalent  0 ==  A. 

Form  10  (OTHER)  involving  predicates  uses  these  predicates  in 
a roughly  equivalent  fashion  (numbers  range  from  9 to  29),  except  for 
an  AED  preference  for  the  ==  predicate  (48  occurrences).  These 
"OTHER"  forme  would  probably  be  most  frequently  represented  by  the 
form: 

• Expression  ="-  expression; 

(e.g.  (A+B)  ==  (C+D)). 

Forms  (6)  and  (O'1  receive  some  slight  use  and  again  the  use  of 
these  forms  with  the  four  groups  of  predicates  are  all  roughly  equivalent 
except  for  a few  cases:  AED  prefers  the  forms  expression  ==  0 (43 
occurrences)  and  expression  -»  = 0 (42  occu • vences).  While  J3B  prefers 
the  form  expression  ==  literal  other  than  0 (44  occurrences),  and  to 
some  extent  the  form  expression  ==  0 (27  occurrences). 

In  form  10,  the  uses  of  AND  and  OR  are  used  roughly  equally  by 
both  AED  and  J3B;  AED  preferring  AND  (188  to  110)  and  J3B  prefei-ring 
OR  (176  to  103).  J3B  has  almost  no  other  use  cf  these  connective  and 
AED  has  a comparatively  modest  use  with  form  (5).  A spot  check  of  the 
source  language  code  shows  that  the  most  frequent  use  of  AND  and  OR 
are  in  expressions  like  the  following  examples' 

• A B AND  C ==  D, 

• A ~~  B OR  C *-  D. 

Other  predicates  than  ==  occur  in  these  forms,  «nd  B and/or  D are  frequently 
replaced  by  literals. 


KpL '.  w^»v/  TSST  ;;rJ?>li^ . 7-r 


By  far  the  most  frequently  used  predicate  is  ==  in  both  compilers 
with  the  second  most  frequent,  -j  =.  The  other  two  predicates  are  used 
somewhat  less  and  are  more-or-less  used  with  approximately  equal 
frequency. 

The  surprising  lack  of  any  usage  whatsoever  of  certain  forms 
prompted  a review  and  retest  of  the  data  gathering  tools  to  insure  their 
proper  functioning.  The  results  of  this  activity  confirmed  thaf;  the  tools 
were  operating  correctly  and  that  the  complete  lack  of  usage  of  these 
forms  is  correctly  reported.  In  particular,  it  was  noted  that  rhe  only 
use  of  the  operators  AND  and  OR  out  of  all  the  forms  tested  (except 
form  10)  was  the  form  "variable  OR  variable"  and  "variable  AND 
variable". 

Overall,  Table  10  again  shows  the  AED  and  J3B  profiles  to  have 
a great  deal  of  similarity  with  a few  differences  of  a stylistic  character. 

3.  Bar  Charts  of  Histograms  of  Static  Usage  Patterns  in  the  AED 

and  .T3B  Compilers 

In  this  section  five  histograms  are  presented  which  show  the 
comparative  static  usage  by  the  AED  and  J3B  compilers  of  a variable 
number,  n,  of  constituent  components  within  five  categories  of  state- 
ments. The  subject  matter  with  which  these  histograms  deal  were 
listed  in  Section  1.  With  each  histogram  interpretive  information  is 
presented  to  explain  the  data  in  the  histogram.  In  addition,  observations 
are  offered  concerning  Ihe  patterns  shown  in  the  histograms. 

Procedure  and  function  calls  usir*£  n arguments.  This  histogram 
(Figure  10  ) shows  that  the  great  majority  of  procedure  caL3  have  five 
or  fewer  arguments,  with  one  argument  being  the  most  common.  Calls 
to  functions  as  well  as  procedures  are  included  in  the  data.  The  overall 
impression  is  clearly  one  of  great  similarity  between  the  AED  and  J3B 
profiles  with  respect  to  the  use  of  arguments  within  procedure  calls. 
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Assignment  statements  with  n right  hand  side  operators.  The 
data  presented  in  this  histogram  (Figure  11  ) counted  only  the  arithmetic 
operators  (+,  *,  and  /)  in  assignment  statements.  However,  a spot 

check  of  the  source  language  code  found  very  few  examples  of  other 
operators  used  in  assignment  statements.  There  were  some  occurrances 
of  the  form: 

• A = F (...), 

Where  a function  call  is  invoked  on  the  right  hand  side  (R.  H.  S. ) and  the 
returned  value  is  assigned  to  the  variable  on  the  left  hand  side.  Occurrences 
of  this  form  would  be  countered  as  0 R.  H.  S.  operators,  but  they  are  very 
rare  compared  to  the  forms: 

w A = literal,  and 

e A = B. 

This  histogram  clearly  p.nows  the  overwhelming  preponderance 
of  simple  assignment  statements,  having  no  R.H.S.  operators.  In 
fact,  very  few  statements  have  more  than  one  operator.  The  two  com- 
pilers show  very  similar  profiles  with  respect  to  this  category. 

Boolean  expressions  with  n operators.  The  Boolean  expressions 
counted  in  the  data  shown  in  this  histogram  (Figure  12  ) were  all  in  IF 
t clauses.  However,  a spot  check  of  the  source  language  programs 

showed  other  occurrences  of  Boolean  expressions  (for  example  in 
assignment  statements)  to  be  very  rare  in  comparison  to  the  counted 
occurrences.  The  operators  countered  were  six  predicates  (==,  <, 

<=,  >,  >=,  -i=)  and  two  correctives  (AND,  OR). 

Here  again  the  AED  and  J3B  profiles  are  seen  to  be  very  similar. 

An  interesting  pattern  of  heavier  usage  of  odd  numbers  of  operators 
(1,  3,  5,  etc. ) is  evident.  This  is  reasonable,  considering  the  fact  that 
many  Boolean  expressions  are  of  the  forms: 

• IF  A ==  B (lup) 

• IF  A ==  B OR  C -=  D (3  ops) 

e IF  A ==  B OR  C -=  D OR  E ' = F (5  ops ) 

etc. 
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Figure  11.  Histogram  of.  Static  Occurrences  of  Assignment  Statements  with  a 
Right  Hand  Side  Operators 
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•gram  of  Static  Occurrences  of  Boolean 
essions  with  n Operators 


The  histograms  also  show  that  by  far  the  greatest  number  of  expressions 
are  of  the  two  forms: 

• IF  A (0  operators) 

• IF  A OP  B (1  operator) 

with  the  second  form  (1  operator)  being  the  most  common.  From  the 
data  presented  in  Section  2,  it  is  clear  that  the  operator  used  here  is 
a predicate,  and  most  usually  ==. 

FOR  loops  and  executable  statements  nested  n deep.  Both 
histograms  dealing  with  FOR  loops  (Figures  13  and  14  ) show  clearly 
that  multiple  nesting  of  loops  is  very  rare  in  both  compilers.  Both 
J3B  and  AED  contains  a few  nested  loops  of  level  2;  J3B  contains  one 
3 -level  nest,  and  AED  contains  none.  Another  observation  seen  by 
comparing  the  two  histograms  with  each  is  that  there  are  about  three 
executable  statements  on  the  average  in  a FOR  loop. 

Both  histograms  again  show  a great  similarity  in  the  AED  and 
J3B  profiles. 

4.  Bar  Charts  of  Frequency  Histograms  of  Relative  Static  Usage 

of  AF.D  Language  Forms 

In  this  section  twleve  bar  graphs  are  presented  which  show  the 
comparative  percentage  of  static  usage  for  various  AED  language 
elements  in  the  source  language  code  of  AED  and  J3B  compilers.  Four 
of  the  bar  graphs  (Figures  15,  16,  17,  and  13)  show  the  percentage 
of  static  usage  among  groups  of  statements  and  clause  types  alone  and 
in  contexts.  The  next  four  bar  graphs  (Figures  19,  20,  21,  and 
22)  show  the  percentage  of  usage  of  arithmetic  and  Boolean  operators 
and  forms.  The  last  four  bar  charts  (Figures  23,  24,  25,  and  26) 
present  histograms  of  the  percentage  of  static  usage  of  four  AED 
language  contexts  involving  a variable  number,  n,  of  a specified 
constituent.  The  twelve  subject  matters  with  which  these  twelve  bar 
charts  deal  were  listed  in  Section  1. 
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Figure  16.  % of  Static  Use  of  Statement  Types  Following  'THEN* 
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Statement  types.  This  bar  graph  (Figure  15  ) shows  the  relative 
frequency  of  occurrence  of  the  six  statement  types:  assignment, 
procedure  or  function  call,  IF-THEN,  GOTO,  IF-THEN -ELSE,  FOR. 

The  IF-THEN  constructions  were  counted  separately  from  the  IF-THEN - 
ELSE  constructions.  The  overall  impression  is  one  of  extreme  matching 
between  the  AED  and  J3B  profiles. 

Statements  following  "THEN".  "ELSE11,  or  "DO",  The  bar 
charts  (Figures  16  , 17  , and  18  ) show  the  relative  frequency  cf  six 
statement  types  (listed  below)  following  one  of  the  keywords,  THEN, 

ELSE,  or  DO  respectively.  The  keyword  THEN  occurs  in  both  the 
IF-THEN  and  IF-THEN -ELSE  constructions.  DO  occurs  in  FOR 
statements  to  introduce  the  loop  to  be  iterated.  The  six  statement  types 
are: 

• BEGIN  (beginning  a BEGIN -END  block) 

• CALL  (a  procedure  call) 

• GOTO 

• Assignment 

• IF 

• FOR 

After  "THEN".  As  expected,  a sequence  of  statements  in  a 
BEGIN-END  block  (BEGIN)  usually  follow  "THEN".  This  statistic  may 
be  slightly  exaggerated  by  the  stylistic  habit  of  some  programmers  who 
always  use  a BEGIN-END  construction  following  a THEN,  even  though 
a single  statement  is  used  within  the  block  (in  which  case  the  BEGIN-END 
is  not  needed).  The  use  of  this  block  form  causes  a different  and  more 
distinctive  format  of  printout  from  the  AED  reformatting  processor 
(PRALG),  and  is  preferred  by  some.  Also,  if  later  corrections  add 
statements  following  the  THEN,  the  editing  task  is  simplified  if  a 
BEGIN-END  already  exists  in  the  source  program. 

The  use  of  call,  GOTO,  and  assignment  statements  following  THEN 
appears  to  be  used  with  about  equal  frequency,  with  AED  showing  more 
calls  than  J3B;  IF  statements  are  used  somewhat  less.  FOR  is  almost 
never  used  in  AED,  and  never  in  J3B. 
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After  "ELSE”.  The  statement  types  following  El  SE  (Figure  17  ) 
show  a significant  different  in  their  usage  pattern  from  'fie  THEN  case. 
Compound  statements  are  much  less  dominant,  and  the  IF  form  is 
much  more  popular.  This  i*  probably  caused  by  the  popular  technique 
of  testing  for  a condition  in  a THEN,  and  then  continuing  to  refine  the 
choice  in  the  ELSE  clause,  resulting  in  IF -THEN -ELSE -IF  sequences. 
Another  usage  difference  shown  in  Figure  17  is  that  instead  of  being 
approximately  equal  in  usage,  assignments,  calls,  and  GOTC's  are 
used  in  that  order  of  popularity. 

Overall,  the  profiles  shown  in  Figure  17  are  seen  to  be  very 
similar,  but  there  are  a few  noticeable  differences.  J3B  appears  to 
have  a higher  preference  for  the  IF-THEN-ELSE  IF  construction  than 
AED  uses,  and  AED  has  a preference  for  IF-THEN-ELSE  BEGIN  which 
is  not  used  as  frequently  by  J2B. 

After  "DO".  In  Figure  18  , it  is  seen  that  the  statement  types 
following  "DO"  show  a very  heavy  use  of  assignments  in  J3B  and  a very 
heavy  use  of  IF  in  AED.  This  lack  of  agreement  in  the  AED  and  J3B 
profiles  is  probably  because  there  are  only  a few  FOR  loops  used  in 
both  compilers.  Thus,  a relatively  small  number  of  one  form  has  a 
major  effect  on  the  percentage  profile.  If  this  explanation  is  correct, 
then  the  importance  of  the  profile  component  shown  in  Figure  17  is 
relatively  unimportant,  and  wojld  contribute  little  to  the  overall 
performance  factor  calculated  for  an  environment  in  which  a compiler 
is  being  evaluated. 

The  complete  absence  of  the  use  of  FOR  following  DO  shows 
that  multiple  nerting  of  loops  is  used  only  within  a BEGi2T-END 
(compound  statement)  block,  and  never  as  the  simple  loop -within -loop 
form. 

Arithmetic  operators.  This  bar  chart  (Figure  19  ) shows  the 
relative  use  of  the  three  categories  of  arithmetic  operators: 

• + or  = (plus  or  minus), 

• * (multiplied  by),  and 

• / (divided  by). 
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Figure  19.  % of  Static  Use  of  Arithmetic  Operators 
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Tae  overall  impression  is  one  of  extreme  similarity  between  the  AED 
and  J3B  profiles.  Figure  19  also  shows  that  * and  / are  very  rare  in 
comparison  to  + and  -,  and  that  * and  / are  used  about  equally. 

Arithmetic  forms.  This  bar  chart  (Figure  20  ) shows  the 
relative  use  of  the  following  six  categories  of  arithmetic  forms: 

. • A OP  1,  2 --  variable  operator  specific  literal  (1  or  2 
depending  on  operator  used  --  see  Section  2). 

• A OP  B --  variable  operator  variable. 

• A OP  L*  --  variable  operator  literal  other  than  1 cr  2 
as  specified  above. 

• OP  1,2  --  arithmetic  expression  operator  specific 
literal  (1  or  2 as  above). 

• E OP  L.*  --  arithmetic  expression  operator  literal 
other  than  1 or  2 as  specified  above. 

• OTHER  --  all  other  arithmetic  forms. 

A spot  check  of  the  source  language  found  that  the  OTHER  category  was 
almost  exclusively  the  form 

• Arithmetic  expression  operator  arithmetic  expression 

such  as  (A+B)  * (C+D),  although  a small  number  of  other  forms  were 
also  seen. 

The  overall  impression  from  Figure  20  is  that  this  aspect  of 
the  profiles  again  find  significant  similarity  between  the  AED  and  J3B 
compilers.  However,  there  are  some  noticeable  stylistic  differences. 
AED  has  a slight  preference  for  the  A OP  1,  2 form  over  the  forms 
A OP  B and  A OP  L which  are  used  about  equally.  On  the  other  hand, 
,T3B  uses  the  forms  A OP  B,  A OP  1,  2,  and  A OP  L in  a definite 
decreasing  pattern.  The  AED  and  J3B  use  of  the  OTHER  form  is 
similar,  with  J3B  using  it  somewhat  more.  The  use  of  the  forms 
E OP  1,  2 and  E OP  L are  comparatively  rare  in  both  AED  and  J3B, 
and  are  used  about  equally  in  both  compiler  a. 
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Figure  20.  % of  Static  Use  of  Arithmetic  Forms 
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Boolean  operators.  This  bar  chart  (Figure  21)  shows  the 
relative  use  of  four  categories  of  predicates  (listed  below)  and  the 
Boolean  connectives  AND  and  OR.  The  predicate  categories  are: 

• EQL  (==) 

• NEQ  <-,=), 

• GEQ+GRT  (>=  and  >),  and 

• LEQ+LES  (<=  and  <). 

Figure  21  shows  the  EQL  and  NEQ  (==  and  =)  are  the  most 
common  Boolean  operators,  with  EQL  being  far  more  popular  than  all 
others.  The  remainder  of  the  operators  are  used  about  equally. 

The  overall  impression  from  Figure  21  is  again  that  the  AED 
and  J3B  compilers  have  similar  profiles. 

Boolean  forms.  This  bar  chart  (Figure  22  ) shows  the  relative 
use  of  the  following  five  categories  of  Boolean  forms  as  used  in  IF 
clauses: 

• A PR  L*  --  variable  predicate  literal  other  than  0. 

• A.  FR  B --  variable  predicate  variable  te  that  a 
insignificant  number  of  forrr.r  using  Ai  and  OR  and 
Boolean  variables  are  included  in  this  category). 

• A PR  0 --  variable  predicate  0 (literal), 

• E PR  L - - arithmetic  expression  predicate  literal 

• OTHER  --  all  other  forms. 


A spot  check  of  the  source  language  code  showed  that  members  of  the 
OTHER  category  are  primarily  of  a form  of  which  the  following  is  a 
representative  example: 

• A==B  AND  C==D 

Here  ==  often  is  replaced  by  -,=,  and  B and  D are  often  literals. 

In  Figure  22  we  note  the  high  preference  of  J3B  for  the  form 
A PR  L*,  and  the  more  moderate  preference  of  AED  for  the  form 
A PR  B not  shared  by  J3B.  However,  the  overall  impression  from 
Figure  22  is  rough  similarity  between  the  AED  and  J3B  profiles.  If 
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Figure  22.  % of  Static  Use  of  Boolean  Forms 
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the  first  three  categories  are  combined,  the  resulting  percentages  would 
be  approximately  70%  for  J3B  and  62%  for  AED.  The  regrouped  profiles 
using  these  values  would  then  be  very  similar. 

% of  arithmetic  operators  with  n R.H.S.  operation s . This 
histogram  (Figure  23  ) shows  that  the  great  majority  (roughly  80%)  of 
R.H.  S.  forms  have  no  operators.  This  result  emphasizes  the  observa- 
tion assignment  statements  are  generally  very  simple  in  both  compilers. 

A spot  check  of  the  forms  used  in  arithmetic  assignment  state- 
ments showed  that  they  are  typified  by  the  following  examples: 

• A = B 

• A = literal 

Here,  A or  B are  frequently  bead  components  as  well  as  declared  integer 
variables.  It  should  be  noted  that,  through  an  oversight  in  the  instrumented 
compiler  used  to  gather  the  data,  all  Boolean  assignment  statements 
were  erroneously  added  into  the  "0  - RHS"  left-most  column,  (e.g. 

A = B AND  C).  Since  all  forms  of  Boolean  assignment  are  very  rare, 
it  is  qui',2  unlikely  that  this  introduced  any  sizeable  error  in  the  data 
as  shown.  The  spot  check  also  found  that  the  bulk  of  the  remaining 
arithmetic  assignments  (roughly  20%)  were  of  the  forms  typified  by  the 
following  examples: 

• A = B i 1 

• A = B f literal  other  than  1 

• A = B i C 

There  is  a clear  overall  impression  from  the  histogram  of 
Figure  23  that  the  AED  and  J3B  profiles  are  extremely  similar  with 
respect  to  the  use  of  operators  in  arithmetic  assignment  statements. 

% of  Boolean  expressions  with  a operators.  The  Boolean 
expressions  counted  in  generating  the  data  comprising  the  histogram 
of  Figure  24  were  only  those  occurring  in  an  IF  clause.  However, 
all  other  occurrences  of  Boolean  expressions  are  extremely  rare  in 
the  two  compilers.  The  Boolean  operators  counted  included  six  predicates 
(==,  -i=,  <,  <=,  >,  >=)  aid  the  two  connectives  AND  and  OR. 
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Figure  23.  % of  Static  Use  of  Arithmetic  Assignments  with  n R.H. S.  Operators 
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Note  that  approximately  887o  of  all  Boolean  expressions  in  both 
compilers  occur  with  0 or  1 operators.  A spot  check  of  the  source 
language  programs  found  for  the  0 operator  case  only  the  form  IF  A, 
where  A was  a Boolean  variable.  For  the  1 operator  case,  the  spot 
check  found  only  the  form  IF  A predicate  B,  where  A and  B were  integer 
arithmetic  variables,  and  predicate  was  usually  ==  or  -j=.  Boolean 
expressions  involving  2 or  more  operators  are  seen  to  be  very  rare. 

The  overall  impression  from  Figure  24  is  again  a significant 
degree  of  similarity  between  the  AED  and  J3B  profiles. 

% of  procedure  and  function  calls  with  n arguments.  The 
histogram  presented  in  Figure  25  shows  that  approximately  907o  of 
all  procedure  and  function  calls  have  three  or  fewer  arguments  for 
both  the  AED  and  J3B  compilers.  The  overall  impression  in  Figure  25 
is  again  a high  degree  of  similarity  between  the  AED  and  J3B  profiles. 

% of  executable  statements  nested  n deep  in  FOR  loops.  The 
histogram  of  Figure  26  shows  that  almost  all  executable  statements 
occur  outside  of  FOR  loops.  This  is  easily  understood  since  there  are 
relatively  few  FOR  statements  used  in  the  AED  and  J3B  compilers,  and 
it  has  been  observed  (Section  2)  that  on  the  average  only  three  executable 
statements  appear  in  each  FOR  loop.  This  result  of  course  causes  the 
AED  and  J3B  profiles  to  be  very  similar  with  respect  to  this  category 
of  AED  language  usage. 
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Figure.  26.  % of  Static  Occurrences  of  Executable  Statements 

Nested  n Deep  in  FOR  Loops 
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CHAPTER  12 

DYNAMIC  COMPILER  DEMAND  PROFILE  DATA 


1. 


Overview 


This  chapter,  together  with  the  companion  chapter  entitled 
"Static  Compiler  Demand  Profile  Data"  (Chapter  11),  presents  a summary 
of  all  non-timing  data  gathered  during  the  project.  Dynamic  data  is 
presented  in  this  chapter  in  the  same  form  as  was  the  static  data  in 
Chapter  11.  It  is  suggested  that  the  reader  should  first  become  familiar 
with  the  static  data  discussion  before  preceding  with  a review  of  the 
information  presented  in  this  chapter. 

The  dynamic  data  was  obtained  using  the  results  of  the  static 
data  gathering  effort  as  a basis.  Static  data  counts  for  each  source 
language  procedure  in  each  of  the  AED  and  J3B  compilers  were  multiplied 
by  a weighting  factor  to  obtain  comparable  dynamic  values.  The  weighted 
counts  for  each  procedure  were  then  summed,  to  obtain  grand  total 
weighted  counts  for  each  compiler. 

The  weighting  factors  applied  to  each  procedure  were  derived 
by  running  a version  of  each  compiler  which  was  modified  to  keep  a 
record  of  the  number  of  times  each  program  in  the  compiler  was  entered. 
Each  compiler  was  run  twice,  using  two  specially  devised  test  programs 
as  compiler  input.  (These  test  programs  are  presented  in  Appendix  2.  ) 
The  total  number  of  calls  for  each  compiler  program  was  printed,  and 
the  sum  of  the  number  of  calls  for  the  two  tests  was  calculated  as  the 
desired  weighting  factor.  Thus,  if  procedure  A were  called  forty  times 
during  test  1 and  sixty  times  during  test  2,  and  procedure  B were  called 
once  during  test  1 and  never  during  test  2,  then  A would  be  assigned  a 
weighting  factor  of  100,  and  B would  be  assigned  a weighting  factor  of  1. 
Thus  each  static  data  count  for  procedure  A would  have  100  times  the 
importance  of  procedure  E in  contributing  to  the  grand  totals  of  the 
dynamic  compiler  demand  profiles. 

It  should  be  noted  that  this  weighting  factor  technique  has  several 
features  which  influence  the  interpretation  of  the  dynamic  profile  results: 
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• Frequently,  not  all  statements  of  a program  are  executed 
once,  each  time  it  is  executed.  A loop  may  cause  one 
set  of  statements  to  be  executed  several  times  for  one 
execution  of  the  procedure,  or  a GOTO  RETURN,  IF-THEN- 
ELSE  (or  other  form  of  conditional  statement)  may  cause 

a set  of  statements  never  to  be  executed  at  all.  The 
weighting  technique  used  does  not  take  these  factors  into 
account. 

• All  error  diagnostic,  recovery,  and  print  programs  are 
eliminated  from  the  statistics,  since  both  test  cases  were 
designed  to  compile  correctly  with  no  errors,  and  t j.s 
caused  the  weighting  factor  to  be  0 for  all  error -handling 
programs  in  each  compiler. 

• The  weighting  factor  is  a direct  consequence  of  the  style 
and  contents  of  the  two  test  cases.  It  is  believed  that  a 
reasonable  mix  of  statements  and  programming  styles  were 
used  in  writing  the  two  tests,  but  it  should  be  noted  that 
any  language  feature  which  was  not  employed  in  either  test 
and  which  is  the  only  cause  for  calling  a particular  compiler 
subroutine,  results  in  that  particular  subroutine  to  have  a 
weight  of  0. 

In  the  following  pages,  the  dynamic  data  is  grouped  into  tables 
and  bar  charts  in  exactly  the  same  form  as  the  static  data  appears  in 
Chapter  11.  The  reader  should  compare  the  corresponding  static  data 
table  or  bar  chart  with  its  dynamic  counterpart  to  see  how  the  results 
are  effected  by  applying  the  dynamic  weights.  In  general,  the  dynamic 
data  shows  the  same  general  results  as  was  seen  in  the  static  data, 
except  as  noted  in  the  text  accompanying  each  table  or  bar  chart. 

2.  Tables  of  Dynamic  Usage  of  AED  Language  Forms  in  the  AEP 

and  J3B  Compilers 

In  this  section  seven  tables  are  presented  which  are  the  dynamic 
data  counterparts  of  the  tables  of  static  data  presented  in  Section  2 
of  Chapter  11. 

Statement  types,  operators,  and  labels.  Table  1 1 is  the  dynamic 
counterpart  of  Table  4. 

The  relative  dynamic  usage  of  various  statement  and  operation 
forms  is  very  similar  to  the  static  figures.  In  both  compilers,  call 
statements  dropped  slightly  in  importance,  while  IF  and  GOTO  statements 
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increased.  Usage  of  Boolean  operations  remained  far  ahead  of  arithmetic 
operations.  The  increase  in  the  importance  of  IF  and  GOTO  in  the 
dynamic  evaluation  tends  to  indicate  that  these  forms  are  used  more 
frequently  in  the  repetitive  portion  of  the  compilation  process,  whereas 
they  are  less  frequently  used  in  the  initialization  and  error  reporting 
areas. 

Assignment  statement  forms.  Table  12  is  the  dynamic  counterpart 
of  Table  5.  Here  again,  very  small  changes  in  relative  importance  are 
noted  between  the  static  and  the  dynamic  data.  In  both  compilers,  the 
forms  "A  = B"  and  "A  = EXPRESSION"  assumed  slightly  more  importance 
in  the  dynamic  data,  while  "A  = FUNCTION  (...)"  assumed  less 
importance.  The  later  effect  verifies  the  slight  drop  in  function  call 
importance  noted  in  Table  9 on  dynamic  usage  of  statement  forms. 

Statement  types  used  with  conditionals  and  loops.  Table  1?  is 
the  dynamic  counterpart  of  Table  6,,  Most  of  the  variation  from  the 
static  data  introduced  by  the  dynamic  use  of  weighting  factors  is  seen 
to  be  generally  unimportant.  Increases  or  decreases  shown  in  one 
compiler  are  offset  by  the  opposite  trend  in  the  other  compiler.  The 
exceptions  are: 

• The  BEGIN  category  (compound  statement  form)  decreased 
in  both  THEN  and  ELSE  categories,  but  increased  in  the 
DO  category.  This  was  a trend  in  both  compilers. 

• GOTO  increased  in  both  the  AED  and  J3B  compilers  for 
the  THEN  clause,  and  decreased  slightly  in  the  ELSE 
category. 

• In  the  DO  case,  IF  decreased  and  assignment  statement 
usage  increased  in  both  compilers. 

There  is  no  apparent  rationale  for  these  slight  changes,  except  for 
statistical  anomalies  that  are  possibly  introduced  by  the  factors  listed 
in  Section  1. 


FOR  statement  sub-types.  Table  14  is  the  dynamic  counterpart 
of  Table  7.  The  UNTIL  and  WHILE  forms  of  loop  termination  varied 
dramatically  between  the  static  and  dynamic  figures.  In  the  J3B  compiler 
the  relative  importance  of  the  two  forms  was  reversed,  with  WHILE 
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dominating  the  dynamic  data  and  UNTIL  dominating  the  static  data.  No 
such  reversal  was  evident  in  AED.  It  can  only  be  concluded  that  an 
insufficient  number  of  FOR  loops  within  too  few  source  language  modules 
were  reflected  in  the  weighting  factors  and  that  the  results  are  therefore 
distorted  by  the  inadequacy  of  the  statistical  sample. 

Integer  forms  in  FOR  statements.  Table  15  is  the  dynamic 
counterpart  of  Table  8. 

The  set  of  data  shown  in  Table  15  also  suffers  from  too  small  a 
sample  to  perform  an  adequate  evaluation,  as  was  also  the  care  for  the 
static  data  in  Table  8.  From  the  numbers  shown,  the  dynamic  results 
show  substantially  the  same  patterns  as  the  static  data  of  Table  15. 

That  is,  the  initial  index  variable  is  usually  set  to  a literal  or  variable; 
the  step  increment  is  almost  always  1,  and  the  terminating  value  is 
usually  a literal  (not  1)  or  a variable. 

Arithmetic  forms.  Table  16  is  the  dynamic  counterpart  of 
Table  9. 

Table  16  shows  the  same  overwhelming  use  of  + or  -,  and  the 
rare  use  of  and  that  was  evident  in  Table  9.  The  very  small 
total  number  of  and  "/"  operators  in  the  two  compilers  makes 
this  classification  too  small  a sample  for  determining  good  static/ 
dynamic  trend  comparisons.  In  examining  the  individual  forms  of 
arithmetic  phrases,  no  clear  trend  is  obvious.  Most  increases  in 
dynamic  data  tor  J3B  are  offset  by  decreases  in  the  same  category  for 
AED  and  vice-versa.  The  category  "A"  OP  E“  remains  the  most 
commonly  used  form  for  the  "+"  and  ’ operators;  "EXPRESSION  OP 
LITERAL"  and  "A  OP  LITERAL"  are  the  most  commonly  used  arithmetic 
forms  using  the  or  "/"  operators. 
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Boolean  forms.  Table  17  is  the  dynamic  counterpart  of  Table  10. 

The  dynamic  data  shows  the  EQL  (==)  operator  still  by  far  the 
most  commonly  used,  with  the  other  operators  showing  no  significant 
trend  in  the  dynamic  versus  static  comparison.  In  comparing  the 
dynamic  use  of  various  forms  of  Boolean  expressions,  thd  forms 
"A  OP  LITERAL"  and  "A  OP  B"  are  seen  to  be  the  most  commonly 
used,  as  was  also  the  case  in  the  static  data. 

3.  Bar  Charts  of  Histograms  of  Dynamic  Usage  Patterns  in  the 

AED  and  J3B  Compilers 

In  this  section  five  histograms  are  presented  which  are  the 
dynamic  counterparts  of  the  histograms  presented  in  Section  3 of 
Chapter  11. 

Procedure  and  function  calls  using  n arguments.  The  histogram 
presented  in  Figure  27  is  the  dynamic  counterpart  of  the  histogram 
presented  in  Figure  10. 

The  weighted  statistics  shown  in  the  histogram  of  Figure  28 
show  that  the  majority  of  procedures  are  called  with  three  of  fewer 
arguments,  as  was  also  seen  in  the  static  histogram  (Figure  10).  The 
most  noticeable  change  in  the  static  versus  dynamic  histograms  is  a 
sizeable  increase  in  the  calls  using  1 and  2 arguments  in  J3B,  with  an 
opposite,  leveling  out  effect  in  AED.  This  indicates  that  procedures 
with  fewer  arguments  are  called  in  the  heaviest  used  J3B  compiler 
programs,  while  the  opposite  is  true  for  AED.  There  is  no  apparent 
explanation  for  thin  result  except  for  the  statistical  anomalies  that  are 
possibly  introduced  by  the  factors  listed  in  Section  1. 

Assignment  statements  with  n right  hand  side  operators.  The 
histogram  presented  in  Figure  28  is  the  dynamic  counterpart  of  the 
histogram  presented  in  Figure  11. 

The  number  of  assignment  statements  having  no  right  hand  side 
(R.H.  S.  ) operators  remaind  dominant  using  the  weighted  data.  The 
static  and  dynamic  histograms  show  very  little  effect  in  any  area 
caused  by  the  use  of  dynamic  weighting  factors. 
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FOR  loops  and  executable  statements  nested  n deep.  The  histograms 
presented  in  Figures  30  and  31  are  the  dynamic  counterparts  of  the 
histograms  presented  in  Figures  13  and  14  respectively. 

The  dynamic  weights  caused  the  AED  statistic  for  use  of  FOR  loops 
at  a nesting  depth  of  2 to  be  greatly  increased,  while  the  J3B  statistics  were 
relatively  unchanged  due  by  the  weighting  effect.  The  loop  at  a nesting 
depth  of  3 seen  in  the  static  data  had  its  weighted  count  reduced  to  0,  since 
the  program  containing  this  loop  was  never  entered  in  either  of  the  two 
J3B  test  cases  processed. 
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The  reason  for  the  odd  change  in  the  AED  statistic  5 s the  feet  that 
FOR  loops  are  used  rarely  and  that  the  few  procedures  in  AED  using  FOR 
loops  were  called  with  a relatively  high  frequency,  thereby  resulting  in  a 
high  weighted  count. 

In  comparing  Figures  31  and  14,  we  see  that  when  the  number  of 
executable  statements  is  taken  into  account,  the  unusual  height  of  the  AED 
2 level  bar  in  Figure  14  no  longer  shows  up  in  the  histogram  of  Figure  31. 
On  the  other  hand,  a new  separation  of  the  AED  and  J3B  profiles  'a  seen  in 
the  level  1 bars,  where  the  J3B  bar  increases  substantially  as  compared 
with  the  AED  bar.  The  reasons  for  this  odd  behavior  is  probably  again 
due  to  the  inadequacy  of  the  statistical  sample  fc-‘*  FOR  loops. 
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NESTING  DEPTH 

Figure  30.  Histogram  of  Dynamic  Occurrences  of  r OR 
Loops  Nested  n Deep 
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4.  Bar  Graphs  of  Frequency  Histograms  of  Relative  Dynamic  Usage 

of  AED  Language  Forms 

In  this  section  twelve  bar  graphs  are  presented  which  are  the 
dynamic  counterparts  of  the  bar  charts  of  static  data  presented  in  Section  4 
of  Chapter  11. 

Statement  types.  The  bar  graph  presented  in  Figure  32 is  the 
‘ dynamic  counterpart  of  the  bar  graph  presented  in  Figure  15. 

In  Figure  32,  the  dynamic  weighted  data  show  a slight  leveling 
effect  in  comparison  with  Figure  15,  its  static  equivalent.  Assignment  and 
call  statements,  which  comprised  about  two-thirds  of  all  statements  used 
statically,  dropped  to  about  sixty  percent  usage  when  the  dynamic  weights 
are  included.  Correspondingly,  the  IF,  GOTO,  and  ELSE  c^cegory  which 
comprised  about  one -third  of  all  statements  used  statically  rose  to  about 
forty  percent  usage. 


ASSIGNMENT  CALL  IF  --  THEN  GOTO  ELSE  FOR 
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Figure  33.  % of  Dynamic  Use  of  Statement  Types  Following  'THEN' 


After  >ELSEI,  The  dynamic  bar  graph  (Figure  34)  shows  the  same 
relative  usage  patterns  that  appeared  in  the  static  bar  graph  (Figure  17). 
Assignment  statements  in  the  AED  compiler  gained  the  most  in  relative 
frequency  of  occurrence  due' to  the  dynamic  weighting. 
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After  'DO'  . In  Figure  35  it  is  seen  that  the  major  effect  resulting 
from  applying  the  weighting  factors  is  to  level  off  the  differences  between 
the  AED  and  J3B  profiles  in  the  ASSIGNMENT  and  IF  categories.  For 
example,  the  fewer  number  of  assignment  statements  in  FOR  loops  are 
executed  in  the  AED  compiler  more  frequently  than  in  the  J3B  compiler. 

It  should  be  noted  that  the  weights  were  determined  by  the  number  of  times 
the  procedure  containing  the  FOR  statement  was  entered,  rather  than  by  the 
the  number  of  times  the  loop  was  actually  executed;  therefore,  the  number 
of  statements  actually  executed  inside  loops  is  probably  under  represented 
in  the  data  shown  in  the  bar  graph. 
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Arithmetic  operators.  The  bar  graph  presented  in  Figure  36  is  the 
dynamic  counterpart  of  the  bar  graph  presented  in  Figure  19  . 

The  application  of  weighting  facWrs  produced  very  little  effect  in 
the  relative  frequencies  of  use  of  arithmetic  operators.  In  both  the  dynamic 
bar  graph  {Figure  36  ) and  the  static  bar  graph  (Figure  19  ),  the  operators 
"+"  and  occur  with  a frequency  of  about  ninety  percent  for  both  the  AED 
and  J3B  profiles. 
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Arithmetic  forme.  The  bar  graph  presented  in  Figure  37  is  the 
dynamic  counterpart  of  the  bar  graph  presented  in  Figure  20  . 

In  Figure  37  the  dynamic  bar  graph  shows  an  increasing  frequency 
of  occurrence  of  the  form  A OP  B,  while  the  forms  A OP  1,2  and  A OP  L* 
are  reduced  in  frequency  of  occurrence  es  compared  with  the  static  bar 
graph  of  Figure  20  . 

(See  corresponding  sub-section  of  Section  4 in  Chapter  11  for  an 
explanation  of  the  noiation  used  for  labeling  the  bars  of  this  bar  graph. ) 
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Figure  38.  % of  Dynamic  Use  of  Boolean  Operators 


Boolean  forms.  The  bar  graph  presented  in  Figure  39  is  the  dynamic 
counterpart  of  the  bar  graph  presented  in  Figure  25  . 

There  are  no  noteworthy  changes  in  the  differences  between  the 
dynamic  and  static  bar  graphs  of  the  use  of  Boolean  forms. 

(See  corresponding  sub-section  of  Section  4 in  Chapter  11  for  an 
explanation  of  the  notation  used  for  labeling  the  bars  of  this  bar  graph. ) 
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% of  Arithmetic  operators  with  n 1-t.  H.  S.  operators.  The  histogram 
presented  in  Figure  40  is  the  dynamic  counterpart  of  the  histogram  presented 
in  Figure  23  . 

There  are  no  noteworthy  changes  in  the  differences  between  the 
dynamic  and  static  histograms  of  occurrences  of  arithmetic  assignment 
statements  with  n arithmetic  operators. 
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Figure  40.  % of  Dynamic  Use  of  Arithmetic  Assignments  with  n R.H.  S.  Oper?tors 


% of  Boolean  expressions  with  a.  operators.  The  histogram  pre- 
sented in  Figure  41  is  the  dynamic  counterpart  of  the  histogram  presented 
in  Figure  24. 

The  dynamic  histogram  shows  both  significant  increase  in  the  occur- 
rences of  Boolean  expressions  with  1 operator,  and  a reduction  in  the  occur- 
rences with  0 operators,  as  compared  with  the  staiic  histogram.  This 
indicates  that  forms  such  as  IF  A ==  B (1  operator)  are  used  in  procedures 
that  arc  called  frequently,  such  as,  for  example,  in  input  reading  and  code 
generation  procedures.  On  the  other  hand,  the  form  IF  A (0  operators) 
occurs  more  frequently  in  rarely  called  procedures  such  as,  for  example, 
initialization,  error  handling,  etc. 


Dynamic  Use  of  Boolean  Expressions  with  n_  Operators 


Figure  42.  % of  Dynamic  Procedure  and  Function  Calls  With  n Arguments 
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% of  executable  statements  nested  n deep  in  FOR  loops.  The  histo- 
gram presented  in  Figure  43  is  the  dynamic  counterpart  of  the  histogram 
presented  in  Figure  26  . 

Thei'e  are  no  noteworthy  differences  between  the  dynamic  and  static 
histograms  of  the  occurrences  of  executable  statements  nested  n deep  in 
FOR  loops. 
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CHAPTER  13 

HOW  TO  EVALUATE  SPECIAL  FEATURES 


1.  Introduction 

In  this  chapter  a brief  discussion  is  given  on  how  special  features 
might  be  evaluated.  A more  detailed  discussion  would  require  an 
investigation  beyond  the  scope  of  the  present  study.  Section  2 discusses 
the  special  features  question  with  respect  to  ease  of  use  features,  and 
Section  3 discusses  the  question  with  respect  to  case  of  maintenance 
features. 


2.  Ease  of  Use  Features 


Ease  of  use  features  are  matters  of  human  engineering  --  that 
is,  such  features  are  included  in  a compiler  in  order  to  make  a compiler 
easier  to  use. 

Examples  of  such  special  features  are: 

• Diagnostics  that  are  easier  to  use  for  debugging 
purposes. 

• Error  detectors  in  compiled  code  which  are  data 
dependent. 

• Procedure  interfaces  that  check  for  proper  parameter/ 
argument  data  type  matching. 

• Detecting  (nearly)  all  syntr-.tic  errors  during  one 
compilation.  (This  requires  very  good  error  recovery 
mechanisms  during  the  parsing  phase  of  computation.  ) 

• Hooks  for  assisting  the  debugging  of  software: 

• Traces. 

• Breakpoints. 

• Symbolic  debugging. 

• Patching. 


The  benefits  to  be  derived  from  such  features  are: 


• Reduce  the  number  of  debugging  compilations  per 
programming  tasks. 

• Reduce  the  programmer  time  required  to  generate 
debugged  programs. 
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• Reduce  the  experience  required  of  the  programmers  j 

for  obtaining  equivalent  work  output.  \ 

) 

• Increase  reliability  of  programs  believed  to  be 

debugged.  ; 


Each  of  these  factors  can,  in  principal,  be  given  a dollar  value,  although 
for  most  of  these  factors,  there  are  no  techniques  available  to  evaluate 
quantitatively  these  features  with  respect  to  the  above  benefits. 


The  only  research  method  that  suggests  itself  for  assigning  a 
dollar  benefit  valuation  to  these  features  i3  an  elaborate  series  of 
psychological  experiments.  These  experiments  would  be  designed  to 
determine  quantitatively  to  what  extend  the  benefits  indicated  above 
would  actually  occur  from  the  presence  of  an  ease  of  use  feature  in  a 
compiler.  Once  this  information  can  be  obtained,  then  dollar  values 
can  be  assigned  to  these  features  on  the  following  basis. 


• Each  debugging  compilation  represents  a dollar  cost  > 

for  the  use  of  the  computer  facilities  to  perform  the 

compilation,  and  in  addition  for  the  labor  cost  of  the  j 

programmer  in  setting  up  and  interpreting  results  i 

from  a debugging  run. 

• A reduction  in  programmer  experience  requirements 
is  reflected  in  reduced  programmer  salaries. 

* 

• Increased  program  reliability  reduces  maintenance  j 

costs.  '• 

i 

The  above  considerations  indicate  how  future  research  might  be  j 

directed  at  providing  a basis  for  determining  the  dollar  benefit  to  be  j 

) 

associated  with  ease  of  use  features.  The  cost  of  including  these  j 

features  in  a compiler  is  much  harder  to  evaluate.  For  this  reason,  ; 

i 

our  recommendation  is  to  use  a contractural  approach  to  quantify  the 

cost  side  of  the  analysis.  In  particular,  we  recommend  that  a vendor  j 

be  required  to  provide  separate  prices  for  the  inclusion  of  these  features. 

However,  it  is  inappropriate  to  make  such  requirements  for  the  separate 
pricing  o*  features  before  the  dollar  benefit  data  are  available. 


284 


j**^'t8^S^!gSg9W^STft>ia^!J»»X!;fc*wowp«e»iw’wiw»u»»yvfxwwM. ■.■■■■<■  ****** .■».w..,» ..-  ~ - 

I 


• ^^*J^£nsSSES?S35*FP!^SF^5*KESP3Jfy!SES5'!3$GE3s  .7;js-K 


3.  Ease  of  Maintenance  Features 

The  following  topics  are  concerned  with  special  features  of  the 
compiler  which  facilitate  maintenance  functions. 

• Portability  (changing  host  machine). 

• Retargetability  (changing  target  machine). 

• Maintenance  (bug  fixing). 

9 Enhancability  (adding  features ). 

It  is  our  opinion  that  the  simplest  way  to  handle  the  cost/benefit 
evaluation  of  ease  of  maintenance  features  is  by  means  of  including  the 
requirement  of  providing  for  options  in  Requests  for  Proposals.  For 
example,  if  the  buyer  considers  portability  important,  then  the  possibility 
of  wanting  an  additional  compiler  to  run  on  a specific  second  computer 
should  be  firmly  established.  Then,  the  RFP  would  require  the  vendor 
to  provide  an  option  price  and  option  execution  price  for  the  second 
compiler.  If  the  vendor  normally  uses  an  architecture  that  makes 
portability  easy,  the  option  price  will  likely  be  very  low  (perhaps  zero) 
and  the  option  execution  price  will  reflect  the  degree  of  portability  of 
his  architecture.  (That  is,  a poorly  portable  compiler  would  result  in 
an  option  execution  price  similar  to  that  of  Ihe  original  compiler  an 
easily  portable  compiler  would  have  a much  smaller  option  execution 
price.  ) If  the  vendor  would  normally  use  a high  uerformance  architecture 
(to  gain  incentive  profits),  then  the  option  price  might  be  fairly  expensive 
since  vendor  might  choose  a more  portable  architecture  which  would 
reduce  his  expectations  of  incentive  profits. 

Retargetability  can  be  handled  exactly  in  the  same  manner  as 
portability.  Enhancability  can  be  handled  by  specifying  options  for 
specific  features  that  are  anticipated  would  be  added  later  to  an  easily 
enhancible  compiler.  Maintenance  (bug  fixing)  can  be  handled  by  means 
of  warranties  and  options  on  warranties. 
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CHAPTER  14 
CONCLUSIONS 


1.  Introduction 


This  chapter  presents  a summary  of  the  conclusions  reached  as 
a result  of  the  present  study.  For  each  indicated  conclusion,  cross 
references  ar-c  provided  to  the  relevant  sections  of  this  report  which 
contain  supporting  material  for  the  conclusion. 

Section  2 presents  conclusions  for  the  study  as  whole.  Sections 
3,  4,  5,  and  6 present  the  conclusions  from  studying  respectively  the 
architecture  'algorithms  question,  the  same  ei  /ironment  question,  the 
environment  equalizing  question,  and  the  special  features  question. 

(A  full  statement  of  these  four  questions  is  presented  in  Chapter  1.  ) 


2.  Conclusions  from  the  Study  as  a Whole 

Listed  below  the  conclusions  reached  from  the  study  as  a whole. 

• The  main  technical  objective  for  the  study  was  to  develop 
criteria  that  should  be  used  in  measuring  the  performance 
of  compilers.  Thi3  objective  was  achieved  by  the  study. 

(See  Chapter  15  for  a summary  of  the  criteria. ) 

• The  criteria  developed  by  the  study  satisfies  the  application 
objectives  presented  in  Chapter  1.  That  is,  the  criteria 
are  useful  in  selecting  off-the-shelf  compilers,  for 
preparing  RFP's  for  compilers  and  providing  a basis 

for  acceptance  test  design,  and  for  choosing  computer 
haidware  where  compilers  are  to  be  purchased  either 
as  a package  with  the  hardware,  or  separately.  (See 
Ch«'.pter  2 for  an  overview  of  these  uses. ) 

3.  Conclusions  from  Studying  the  Architecture /Algorithms  Question 

Listed  below  are  die  conclusions  reached  from  studying  the 
architecture  /algorithms  question. 

• The  specific  secondary  technical  objective  of  the  study 
was  to  determine  the  answer  to  two  specific  questions: 

• Is  there  a particular  parsing  scheme  that  is  most 

eificient  for  all  languages  and  user  types,  or  is  each 
language  better  suited  by  a unique  parsing  system? 

The  study  determined  the  answer  to  both  parts  to 
be  No!  (See  Chapter  5.  ) 
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• Is  there  a relationship  between  table  searching 
methods  and  the  type  of  language  which  is  being 
compiled?  Thfe  study  determined  the  answer  to 
this  question  to  be  No  ! (See  Chapter  4. ) 

• The  full  statement  of  the  architecture /algorithms  question 
is:  Can  analysis  of  a compiler's  architecture  and 
algorithms  provide  a basis  for  making  valid  judgements 
about  the  performance  that  should  be  expected  from  a 
compiler  ? The  conclusion  reached  in  the  study  is 

that  this  question  should  be  answered  No!  (This 
conclusion  is  supported  by  the  entire  study  of  this 
question  as  described  in  Chapters  3,  4,  5,  6,  and  7.) 

• From  the  study  of  architectural  choices  in  compiler 
design  (Chapter  3),  the  following  conclusions  were 
reached: 

• With  respect  to  compiler  architectures,  one-pass 
compilers  are  faster  and  larger  than  multi-pass 
compilers. 

• Multi-pass  compilers  permit  more  extensive 
optimizations,  and  therefore  can  produce  more 
efficient  object  code. 

• Choices  of  algorithms  for  parsing  and  code 
generation  are  generally  made  for  other  than 
performance  reasons.  Generally,  the  reasons 
relate  to  cost  of  development  of  the  compiler. 

• Some  generalizations  on  the  relative  efficiency  of 
table  look-up  algorithms  are  possible,  but  such 
generalizations  are  mainly  related  to  specific  internal 
architectural  purposes  for  the  table  rather  than 
external  factors  such  as  the  language  being  compiled. 

• Optimization  methods  are  highly  varied,  and  no 
useful  quantitative  generalization  was  found  which 
could  relate  compiler  performance  and  object  code 
quality  for  a particular  individual  or  class  of 
optimizations. 

• From  the  study  of  table  look-up  algorithms  (Chapter  4), 
it  was  concluded  that  each  algorithm  has  performance 
characteristics  that  favor  its  use  for  particular  types 
of  compiler  tables.  The  types  of  tables  that  match 
these  special  performance  characteristics  relate  to 
areas  of  compiler  activity  rather  than  to  typea  of 
languages. 

• From  the  study  of  five  categories  of  parsing  techniques 
(Chapter  5).  the  following  conclusions  were  reached: 


?. 

k 

? 

5. 
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• For  most  parsing  techniques  in  common  use. 
difference**  in  implementation  overshadow 
differences  in  technique  in  impact  on  performance. 

• For  one  technique  category  ("general  techniques"), 
which  is  not  commonly  used  in  compilers,  the 
performance  expected  would  generally  be  poor 
due  to  the  generality  of  the  technique.  This 
expected  poor  performance  is  probably  the  reason 
the  technique  is  not  commonly  used  in  compilers. 

• The  reasons  a particular  technique  is  selected  for 
use  in  a compiler  are  generally  distinctly  independent 
of  performance  considerations. 


& 


• Aside  from  performance  considerations,  it  is 
possible  to  make  some  general  statements  about 
various  advantages  or  disadvantages  one  parsing 
technique  would  be  expected  to  have  in  comparison 
to  the  other  techniques.  (See  Section  4 of  Chapter  5. ) 


• The  study  of  optimization  algorithms  (Chapter  6) 
considered  19  machine  independent  optimizations  and 
9 machine  dependent  optimizations.  This  subject  is 

so  broad  that  no  general  conclusions  seem  appropriate. 
All  optimizations  r. re  intended  to  trade  an  improvement 
in  object  code  quality  for  a reduction  in  compiler  speed. 
Some  are  applicable  to  single  pass  compilers  and  some 
to  multi-pass  compilers,  and  some  to  both.  (See 
Chapter  \ discussion  of  optimizations  and  how  they  fit 
into  architectures. ) 

• The  study  of  code  generation  algorithms  (Chapter  7) 
reached  the  general  conclusion  that  there  is  no 
definite  advantage  or  disadvantage  in  comparing 

three  different  methods  of  organising  and  implementing 
code  generators. 
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4.  Conclusions  from  Studying  the  Same  Environment  Question 

Listed  below  are  the  conclusions  reached  from  the  study  of  the 


E 


same  environment  question. 

• In  Chapter  8,  criteria  are  defined  for  evaluating  compilers 
in  the  same  environment  having  the  same  special 
features.  These  criteria  involve  the  u<*e  of  User 
Profiles  and  Compiler  Performance  Profiles,  both 
based  on  a list  of  language  elements  such  as  those 
listed  in  Section  5 ox  Chapter  8,  These  profiles  can 
be  combined  to  provide  rornpayable  dollar  valuations 
of  such  compilers  by  methods  discussed  in  Section  4 
of  Chapter  8. 


The  list  of  language  elements  for  User  Profiles  presented 
in  Section  5 of  Chapter  8 satisfy  the  objectives  for  the 
list.  These  objectives  are; 

• The  list  is  as  complete  as  ie  reasonable  to  expect 
'vithin  scope  of  the  study. 

• The  list  incorporates  sufficient  detail  so  that  it 
is  reasonable  to  expect  that  no  item  in  the  list 
could  likely  occur  with  an  excessively  high 
frequency  in  user  application  programs.  (The 
proof  of  this  conclusion  requires  the  actual 
generation  of  User  Profiles.  ) 

• It  seems  plausible  that  the  collection  of  User 
Profile  data  for  the  list  could  be  automated. 

(Several  idea;  on  how  this  might  be  done  are 
discussed  in  Section  3 of  Chapter  8.) 

Chapter  9 presents  methods  for  generating  test  programs 
to  be  used  in  collecting  Compiler  Performance  Profile 
data  (for  the  elements  of  the  list  of  User  Profile  language 
elements).  These  methods  satisfy  most  of  the  objectives 
for  such  methods.  These  objectives  are: 

• The  effects  on  compiler  performance  due  to  the 
individual  elements  of  the  list  are  reasonably 
well  isolated  from  each  other. 

• The  number  of  test  programs  which  the  methods 
require  for  the  language  elements  should  be 
small.  However,  for  some  language  elements, 
the  number  becomes  rather  large.  On  the  other 
hand,  the  methods  are  sufficiently  simple  that  the 
generation  of  test  programs  could  be  automated. 

• Th(’  methods  are  easy  to  understand  and  to  put 
into  practice. 

• Tbs  measuring  procedures  specified  (for 
calculating  performar.ee  measured  from  the 
raw  data  collected  from  compiling  and 
executing  the  test  programs)  are  simple  and 
s tr  aightfo  r ward . 


5 . Conclusions  from  the  Study  of  the  Environment  Equalizing 

Question 

Listed  below  are  the  conclusions  reached  from  studying  the 
environment  equalizing  question. 

• It  is  reasonable  to  expect  that  different  compilers 
should  have  similar  Compiler  Demand  Profiles. 

{See  Chapters  11  and  12.) 


289 


A typical  Compiler  Demand  Profile  can  be  used  as  a 
basis  for  defining  a "compiler  Gibson  mix".  (See 
Section  2 of  Chapter  10.  ) 

A "compiler  Gibson  mix"  (established  by  the  methods 
described  in  Section  2 of  Chapter  10)  can  be  used  to 
"equalize"  environments.  (See  Section  3 of  Chapter  10. ) 


Conclusions  from  Studying  the  Special  Features  Question 


The  conclusions  reached  from  studying  the  special  features 
questions  are  listed  below- 

o Assigning  dollar  benefit  valuations  to  ease  of  use  features 
requires  data  not  a present  available.  Psychological 
studies  (described  in  Section  2 of  Chapter  13)  might  be 
useful  for  developing  these  data. 

• Assigning  dollar  cost  valuations  to  ease  of  use  features 
might  be  handled  contracturally.  (See  Section  2 of 
Chapter  13. ) 

• The  cost/benefit  analysis  of  ease  of  maintenance  factors 
could  be  facilitated  by  suitable  use  of  contractural 
methods,  provided  a valid  method  of  determining  a 
dollar  valuation  of  the  performance  of  a compiler  is 
developed.  (See  Section  3 of  Chapter  13. ) 


CHAPTER  15 
RECOMMENDATIONS 

1,  General  Recomman  .ions 

Listed  below  is  a summary  of  suggested  general  recommendations 
for  using  the  results  of  this  study. 

e The  criteria  developed  in  this  study  for  measuring  the 
performance  of  compilers  should  be  used  as  a basis 
for  a number  of  compiler  purchase  activities.  These 
activities  are: 

• Purchasing  off  the  shelf  compilers. 

• Preparing  RFP's  for  compilers  and  designing 
acceptance  tests  with  respect  to  performance 
standards. 

• Choosing  computer  hardware  and  compilers  as 
a package. 

• Choosing  computer  hardware  when  compilers 
are  to  be  purchased  separately. 

(The  criteria  are  summarized  in  Section  2.  How  these  criteria  can  be 
used  is  discussed  in  Section  3. ) 

• The  methods  for  measuring  compiler  performance 
(including  effects  due  to  environmental  factors)  should 
be  used  experimentally  to  establish  their  practical 
suitability  and  to  determine  how  they  should  be 
modified  to  improve  their  usefulness.  (These  methods 
are  described  in  Chapter  8.  ) 

• The  methods  described  in  Chapter  10  should  be  used 
experimentally  to  normalize  the  performance  measures 
derived  by  the  Chapter  8 methods  for  environmental 
differences.  That  is,  experimental  use  of  the  Chapter 
10  methods  should  be  undertaken  to  determine  their 
practical  suitability  in  "equalizing"  environments. 

• Further  studies  should  be  pursued  to  determine  data 
needed  to  properly  assign  dollar  benefit  evaluations 

to  ease  of  use  features.  (See  Section  2 of  Chapter  13v  ) 

• Contractural  methods  should  be  developed  to  permit 
dollar  cost/benefit  analysis  to  be  used  in  evaluating 
ease  of  maintenance  features. 
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• A number  of  specific  experimental  studies  should  be 
explored  involving  the  use  of  the  methods  developed 
in  this  study  (Chapters  b and  10)  to  refine  the  methods 
and  to  further  determine  their  usefulness.  (These 
suggestions  for  further  studies  are  presented  in 
Section  3. ) 


2.  Criteria  Developed  in  the  Study 

The  criteria  for  measuring  the  performance  of  compilers  developed 
in  the  present  study  are  the  following: 

• The  basic  criteria  to  be  used  in  evaluating  a compiler 
is  the  dollar  cost  of  the  compiler,  and  the  dollar  benefit 
of  the  compiler.  Other  criteria  presented  below 
constitute  source  information  or  derived  combinations 
of  source  information  which  contribute  to  an  assignment 
of  a dollar  benefit  valuation  to  various  aspects  of  a 
compilers  performance.  (See  Section  4 of  Chapter  8.  ) 

• The  compiler’s  Compiler  Performance  Profile  --  the 
performance  of  a compiler  with  respect  to  elements 
or  constructions  of  the  language  operated  on  by  the 
compiler.  Four  performance  measures  'the  "directly 
measureable  factors")  for  each  element  are  to  be 
determined: 

• How  the  compiler's  time  to  compile  is  effected 

by  occurrences  of  the  element  in  source  programs 
being  compiled. 

n How  the  compilers  space  requirements  (partition 
size)  is  effected  by  occurrences  of  the  element. 

• How  much  CPU  time  is  required  to  execute  the 
object  code  created  by  the  compiler  for  an 
occurrence  of  the  element. 

• How  much  space  is  required  for  the  object  code 
resulting  from  ar.  occurrence  of  the  element. 

• The  user's  applications  programs'  User  Profile  --  the 
relative  number  of  occurrences  of  an  element  or 
construction  of  ttie  language  operated  on  by  the 
compiler  in  the  uoer's  application  source  language 
programs.  (This  ii  the  static  User  Profile. ) Also, 
the  number  of  executions  of  occurrences  of  the 
element  is  normal  use  of  a user's  application 
programs.  (This  the  dynamic  User  Profile.  ) 
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• The  compiler's  Compiler  Evaluation  Profile  --a 
combination  of  User  Profile  and  Compiler  Performance 
Profile  representing  performance  measures  for  each  of 
the  four  "directly  measureable  factors"  with  respect 

to  a "typical"  user  prog,  am, 

• The  performance  of  a computer /operating  system 
environment  with  respect  to  a "compiler  Gibson  mix". 
(See  Chapter  10  for  a detailed  discussion  of  this 
criterion. ) 

e Administrative  data  defining  the  average  degree  of 
re-use  of  user  applications  programs.  This 
information  in  combination  with  the  Compiler 
Evaluation  Profile  can  contribute  to  calculations 
of  a number  of  useful  dollar  valuations  for  a 
compiler.  (See  Section  4 of  Chapter  8.  ) 

3.  How  the  Criteria  Can  Be  Used 


Compiler  acquisition  situations.  The  results  of  our  investigations 
should  be  useful  in  the  acquisition  o'  hardware  and  compilers  in  the 
following  situations: 

e Hardware  selection. 

• Buying  off-the-shelf  compilers. 

e Preparing  RFP's  for  compilers  and  designing  acceptance 
tests  for  the  delivered  product. 


With  respect  to  hardware  selection,  there  are  two  cases: 

e Buying  computer  hardware  with  the  intention  of 
acquiring  compilers  separately. 

• Buying  computer  hardware  and  compilers  as  a 
package. 


Our  investigation  of  the  environment  equalizing  question  (Chapter  10) 
supports  the  feasibility  of  establishing  a "compiler  Gibson  mix".  Such 
a "mix"  is  defined  (Chapter  10)  in  terms  of  the  static  Compiler  Demand 
Profiles  for  AED  and  J3B  presented  in  Chapter  11.  Further  work  is 
required  to  develop  the  assembly  language  representation  of  the  elements 
of  the  "compiler  Gibson  mix"  for  one  or  more  computers.  Once  ail 
this  ”fcrk  has  boon  completed,  the  candidate  compu ic i sysicins  couxu 
be  compared  in  terms  of  their  relative  degree  of  support  for  compiler 
activity. 
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In  addition  to  generating  and  using  the  "compiler  Gibson  mix", 
a compiler  purchaser  should  also  generate  and  use  a "user  Gibson  mix" 
based  on  a User  Profile,  which  would  characterize  the  user  programs 
to  be  compiled  and/or  executed  on  the  new  installation.  If  it  is  known 
what  fraction  of  the  time  the  installation  will  be  performing  compilations 
as  executions  of  compiled  program,  then  the  degree  of  compiler  support 
can  be  suitably  weighted  and  combined  with  the  support  expected  for 
User  Programs  to  give  an  overall  dollar  benefit  valuation  for  the 
computer. 

If  hardware  and  compiler  are  to  be  acquired  as  a package,  the 
results  of  our  investigation  of  the  same  environment  question  are 
directly  applicable.  A Compiler  Performance  Profile  could  be  generated 
for  each  hardware  /compiler  pair  which,  when  combined  with  the  User 
Profile,  would  provide  directly  a Compiler  Evaluation  Profile  for  the 
combination.  This  figuie  of  merit  would  characterize  the  performance 
of  the  combination  with,  respect  to  compiling  and  executing  a 'typical" 
user  program. 

If  different  compilers  under  consideration  have  different  features 
which  would  contribute  to  ease  of  use  and  ease  of  maintenance,  additional 
information  derived  from  considerations  of  the  special  feature  question 
would  have  to  be  taken  into  account. 

With  respect  to  buying  off-the-shelf  compilers,  the  results  of 
our  investigation  of  the  same  environment  question  should  also  be 
directly  applicable.  The  generation  of  a Compilei  Performance  Profile 
for  each  compiler,  combined  with  the  User  Profile  will  provide  directly 
a Compiler  Evaluation  FrOiile  tor  each  compiler's  performance  with 
respect  to  a "typical"  user  program. 

Preparing  RFP's  constitues  the  most  complex  problem  of 
determining  how  to  use  the  results  of  the  present  study.  If  a compiler 
for  the  desired  language  already  exists  on  a currently  used  machine, 
different  from  the  host  machine,  then  a Compiler  Evaluation  Profile 
could  be  used  to  define  the  performance  for  the  current  machine  and 


294 


'lfeTf1lVi*?‘i>'“*',i 


compiler.  Then,  the  performance  of  the  computer /operating  system  with 
respect  to  tue  defined  "compiler  Gibson  mix"  could  be  used  to  calculate 
how  an  "equ/v-  Imtly  performing  compiler"  would  perform  on  the  host 
machine.  The  result  of  such  a calculation  would  provide  a base  line  of 
performance  to  be  expected  from  a compiler  acquired  in  response  to  an 
RFP.  These  expectations  could  he  included  in  the  RFP  specsiica.  _ons, 
and  could  also  be  used  to  determine  whether  the  delivered  product 
performed  adequately  well  during  acceptance  testing.  Contr  .~tu  entered 
into  using  these  procedures  should  probably  include  incentives  (and/or 
penalties)  for  performance  better  (or  worse)  than  the  base  line  as 
determined  in  the  above  manner.  The  possibility  of  using  incentives  -c 
discussed  further  below. 

Incentives.  Consider  the  problem  of  specifying  in  an  RFP  the 
required  performance  of  a compiler.  If  the  requirements  are  too 
restrictive,  vendors  will  be  discouraged  from  bidding.  If  requirements 
are  too  loose,  the  compiler  bought  will  not  perform  as  well  as  may  be 
possible  with  existing  technology.  Consequently,  we  believe  the 
possibility  of  performance  incentives  should  be  considered.  An  approximate 
base-line  for  the  expected  performance  can  be  derived  in  the  manner 
discussed  above.  If  a vendor  supplies  a compiler  which  performs  better 
from  this  baseline,  this  difference  in  performance  can  be  assigned  a 
dollar  value.  For  example,  if  a compiler  runs  ten  percent  faster  than 
the  baseline,  this  results  in  a ten  percent  savings  in  computer  expenses 
for  the  useful  life  of  the  compiler.  Some  fraction  of  this  saving  could 
be  returned  to  the  vendor  as  a performance  incentive.  It  will  require 
some  care  in  establishing  the  baseline  and  in  the  incentive  formulas  to 
use  to  get  the  best  performing  compilers  for  each  dollar  expended,  but 
it  is  likely  that  this  approach  will  improve  this  desired  end  result  as 
experience  is  gained.  With  this  approach,  it  is  net  critical  that  the 
baseline  be  as  accurately  determined  as  a set  of  specifications  for  a 
fixed  price  procurement  without  incentives.  If  the  baseline  is  made 
looser,  then  one  should  expect  that  the  base  orice  bid  will  be  smaller, 
since  the  vendor  can  expect  to  make  higher  profits  from  the  incentives. 
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4.  Suggested  Topics  for  Future  Study 

Listed  below  are  some  topics  whose  study  would  contribute  to 
the  establishing  of  well  defined  procedures  in  evaluating  and  procuring 
compilers.  These  topics  are  offered  in  the  light  of  the  present  study, 
and  results  from  exploring  these  topics  are  directly  related  to  the 
criteria  established  by  the  present  study  for  evaluating  compilers. 

• More  Compiler  Demand  Profiles  should  be  determined 
(by  the  methods  described  in  Chapters  10,  11,  and  1Z). 

In  developing  those  profiles,  information  related  to 
more  elements  and  constructions  of  the  source  language 
in  which  the  compiler  is  written  should  be  included. 

The  purpose  of  the  study  should  be  the  improvement 

of  the  "compiler  Gibson  mix"  tentatively  defined  in 
Chapter  10,  based  on  the  present  preliminary  study  of 
how  such  a "mix"  should  be  defined. 

• The  methods  presented  in  Chapter  8 for  automating 
the  collection  of  User  Profile  data  should  be  explored. 
Actual  User  Profiles  should  be  developed.  These 
profiles  should  be  based  on  the  list  of  language 
elements  presented  in  Section  5 of  Chapter  8 as  a 

point  of  departure.  Also,  test  programs  for  determining 
the  performance  of  a compiler  should  be  prepared 
using  the  methods  presented  in  Chapter  5.  These 
test  programs  should  be  compiled  and  executed, 
and  Compiler  Performance  Profiles  should  be 
generated.  The  purpose  of  such  studies  would  be  to 
confirm  the  practical  usefulness  of  the  methods 
presented  in  the  present  study,  and  to  acquire  an 
accumulation  of  experience  in  the  use  of  these 
methods  that  would  provide  the  basis  for  improving 
them. 

• Psychological  studies,  as  discussed  in  Chrpter  13, 
are  necessary  to  develop  data  to  provide  the  basis 
of  assigning  dollar  benefit  values  to  various  ease 
of  use  features. 
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APPENDIX  1 

INSTRUMENTS  USED  TO  GENERATE 
COMPILER  DEMAND  PROFILES 


As  the  term  is  used  here,  "instruments"  are  primarily  counters 
of  the  specific  forms  of  language  elements  and  the  associated  logic  to  detect 
those  forms.  These  instruments  could  havu  been  installed  in  several 
different  points  within  the  AED  compiling  system:  juat  after  the  lexical 
processing  phase,  at  the  parsing  phase  or  at  the  code  generation  phase. 

Our  choice  was  the  code  generation  phase  since,  at  this  point,  most  of 
the  bookkeeping  for  lexical  analysis  and  parsing  is  out  of  the  way,  the 
semantics  of  the  program  have  been  determined,  and  most  importantly, 
all  of  the  significant  processing  passes  through  one  major  system  module 
(COMPILE)  which  can  be  instrumented  in  a simple  manner. 

Since  the  source  program  has  at  this  point  been  transformed  into  an 
intermediate  representation,  a few  language  elements  such  as  parentheses 
and  parentheses  nesting  are  absent  and  can  j.o  longer  be  measured.  Con- 
versely, many  other  language  elements  become  extremely  simple  to 
measure,  especially  those  which  have  fairly  local  context. 

To  see  why  this  is  so  we  must  examine  somewhat  more  closely  the 
form  of  the  AED  intermediate  representation,  which  is  a tree  structure, 
bearing  in  mind  that  this  form  though  widely  used  is  not  a universal  one. 

The  AED  system  module  COMPILE  is  called  within  the  hierarchy. 
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The  compiler  control  box  represents  the  code  generation  phase. 

The  tree  walker  represents  the  roi  tines  which  systematically  (recursively) 
moves  through  tree  structure  representation,  and  calls  COMPILE  for  each 
node  in  the  tree.  The  COMPILE  module  calls  the  instrumentational  module 
(the  statistics  gatherer),  with  appropriate  parameters,  each  time  it  is 
called,  (once  each  time  the  tree  walker  passes  a node).  It  is  this  node- 
by-node  processing  which  makes  the  collection  of  statistics  on  a local 
context  basis  easy  to  implement.  In  addition,  all  relevant  program  logic 
and  variables  for  counters  are  maintained  in  the  statistics  gathering 
routine  and  require  little  additional  support  from  the  AED  compiler. 

After  the  return  from  the  statistics  gatherer,  COMPILE  then  dispatches 
control  to  nui  verous  routines  which  actually  emit  code  for  the  node  being 
processed. 
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Without  going  into  excessive  detail,  we  can  present  a useful 
description  of  the  AED  tree  structure  format,  node  types,  branches,  and 
the  traversal  scheme  used  by  the  tree  walker.  It  is  easiest  to  do  this 
through  actual  examples  of  fairly  simple  program  constructions.  Consider 
the  phrase  A + B + C.  The  AED  compiler  builds  an  interval  tree  for  this 
rvhrase.  which  mav  be  represented  as  follows: 


A+B+C 


/ 


Legend: 


minor  pointer 


left  context  pointer 


right  context  pointer 


/\ 


major  pointers 


O 


operator  node 
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In  the  above  diagram,  the  tree  walker  is  brought  to  the  lowest  level 
node  of  the  subtree  for  A+B+C  via  a minor  pointer  originating  at  some  node 
higher  in  the  tree.  This  node  is  then  passed  to  COMPILE  which  generates 
code  for  'A+B1  after  first  allowing  the  statistics  gatherer  to  examine  the 
node  and  classify  it.  The  variables  'A*  and  'B*  are  pointed  respectively 
by  the  left  and  right  context  pointers  of  the  '+'  node.  A return  is  made  by 
COMPILE  to  the  tree  walker  which  then  takes  the  major  yointsr  to  the 
next  *+'  node.  The  bi-directional  arrow  indicates  that  this  major  pointer 
for  the  lower  •+•  matches  with  the  left  context  pointer  of  the  higher  '+'. 

Another  call  is  made  to  COMPILE  (and  subsequently  to  the  statistics 
gatherer  and  code  is  generated  to  add  'C'  to  'A+B‘.  On  return,  the  major 
I>ointer  for  the  upper  node  is  used  to  reach  the  node  next  in  the  logical 
program  sequence. 

Consider  the  second  example  represented  by  the  diagram  below, 
for  the  statement  A = 0: 


I A = 0 


This  rather  simple  subtree  is  reached  via  a minor  pointer  to  the  "="  node. 
The  statistics  gatherer  (reached  via  COMPILE)  examines  the  left  and  right 
context  and  then  records  an  occurrence  of  an  assignment  statement. 

As  a third  example,  consider  the  statement 
IF  I EQL  J THEN  A = B ELSE  A = C.  This  is  re*  resented  by  the  following 
tree: 


This  third  example  has  four  minor  pointers  which  are  used  to 
traverse  the  tree  it.  the  fol’owing  sequence:  IFj,  EQL,  .IF.,,  THENj,  =, 
THEN2,  ELSE^,  =,  EXjSE2>  where  the  subscript  indicates,  the  first  or 
second  passage  of  the  node,  and  absence  of  an/  subscript  signifies  the  only 
passage.  The  statistics  gathered  in  the  course  of  the  tree  traversal 
collects  counts  for  the  IF-THEN-ELSE  construction  and  its  constituent 


APPENDIX  2 


TEST  PROGRAMS  USED  TO  GENERATE 
COMPILER  DEMAND  PROFILES 


1.  Description  of  Tests 

Section  2,  below,  presents  a listing  of  the  two  test  programs  plus 
all  external  data  declaration  files  used  by  the  two  programs  for  use  in 
the  dynamic  compiler  testing  effort.  Listings  of  both  the  J3B  and  the 
AED  versions  of  the  programs  and  data  files  are  included. 


The  two  groups  of  test  files  are  listed  in 
Section  2: 


File  Name 

Group  1 (J3B) 

1.  FILE  N.KFNUP 

2.  FILE  C.  PNHIT 


Data  Files  Referenced 


J3B  program  FILE  NRBGNAV 
J3B  program  FILE  CPNOWN 
FILE  CNDDATA 
FILE  NRBMAST 
FILE  NRBAUX 
FILE  NRBGNAV 
FILE  CPN CONST 


3. 

FILE  CPNOWN 

J3B  data 

declarations 

(No.»e) 

4. 

FILE  CNDDATA 

J3B  data 

declarations 

(None) 

5. 

FILE  NRBMAST 

J3B  data 

declarations 

(None) 

6. 

FILE  NRBAUX 

J3B  data 

declarations 

(None) 

7. 

FILE  NRBGNAV 

J3B  data 

declarations 

(None) 

8. 

FILE  CPNCONST 

J3B  data 

declarations 

(None) 

Group  2 

(AED) 

1. 

N.KFNUP  AED 

AED  program  NRBGNAV  AED 

2. 

C.  PNKIT  AED 

AED  program  CPNOWN  AED 

CNDDATA  AED 
NRBMAST  A.ED 
NRBAUX  AED 
NRBGNAV  AED 
OPNCONST  AED 
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Data  Files  Referenced 


Group 

2 (AED)  (continued) 

3. 

CPNOWN  AED 

AED  data  declarations 

(None) 

4. 

CNDDATA  AED 

AED  data  declarations 

(None) 

5. 

NRBMAST  AED 

AED  data  declarations 

(None) 

6. 

NRBAUX  AED 

AED  data  declarations 

(None) 

7. 

NRBGNAV  AED 

AED  data  declarations 

(None) 

8. 

CPNCONST  AED 

AED  data  declarations 

(None) 

The  two  programs  (N.KFNUP  and  C.  PNHIT)  were  chosen  to  illustrate 
different  types  of  compiler  usage,  as  can  be  seen  from  a quick  perusal  of 
the  listings.  In  particular,  the  following  features  may  be  observed: 


Program  Features 

N.KFNUP  1.  S.'-ort  program 

2.  Heavy  use  of  "FOR-loops " 

3.  Heavy  use  of  "IF-statements " 

C.PNHIT  1.  Long  program,  including  several  remotely 

inserted  COMPOOL /INSERT  files  of  data 
declarations. 

2.  Heavy  use  of  switches  and  GOTO's, 

3.  Heavy  use  of  logical  bit-operations  w'ith 
masks  (AND,  OR,  XOR,  etc.  ) 


All  files  have  been  carefully  edited  to  prepare  A£D  and  J3B 
versions  of  che  test  programs  which  are  as  identical  as  possible.  For 
example,  the  phrase  "ELSE  BEGIN"  now  occurs  on  the  same  line  in  both 
versions,  whereas  the  original  author  of  the  J3B  program  had  chosen  to 
insert  the  two  words  on  separate  lines,  and  the  original  author  of  the 
AED  version  used  a single  line.  Also,  the  same  remarks  and  comments 
occur  in  both  versions  in  the  same  format. 
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Programs  and  Data  Files  for  J3B  Version  of  Testa 


FILE 


NtKFNUP 


START 

COMPOOL  (NRRGNaV)  1 

l» 

" POSITION  UPDATE  PROGRAM 

it 

OEF  PROC  NUKFPNUP ( t NkFPma  iV  > NKFKGANX ) ? 
BEGIN 


n 

ii 

n 


ii 

* »i 

ii 


W* 


DEFINITION  OK  FORMAL  PARAMETERS 

ARRAY  NKFPMATX  ( 1HR)  F ; ^COVAHIANCF.  MATRIX  ARRAY" 

ARRAY  NKFKuANX  (38)  F \ "KALMAN  GAIN  ARRAY*' 

i 

ENTRY  TO  POSITION  UPOATF.  PROGRAM  ' 

i 

FOR  NKF 1 (0  BY  1 WHILE  NKFI  <=  1)  l "X  AND  Y UPDATE" 

BEGIN 

NKFS  “ NKFCOLMN(NKFI) ♦NKFI  I 

NKFKGD  = NKFP*<ATX(N"-FS)  *NKFRM4TX  5 

FOR  NKFJ  (NKFJ  BY  1 WHILE  NKF  J <r  NKFSTANO)  I 

begin  "Calculate  kalman  gain" 

NKFS  = NKFCCLMN(NKFJ) *nkfi I 

NKFKGANX(NKFI*NKFj)  = NKFPMA1 X (NKFS) /NKFKGD  X 
END  I 

IF  NKFI  a 1 X "KALMAN  GAIN  FOP  Y UPDATE" 

nkfkganx ( i*o)  = nkkpmatx(i) 'nkfkgd  ; 

FOR  NKFJ  (NKFI+1  BY  1 WHILE  NKFJ  <=  NKFSTANO)  ; 

REGIN  "UPDATE  COVARIANCE  MATRIX" 

NKFS  = MKFCOLMN ( NXF I ) + NKF  J I 

FOR  NKFH  (NKFJ  BY  I WKlLt  NKFH  <=  NKFSTANO)  i 
BEGIN 

NKFT  = NKFCOLMN(NKFJ) +NKFH  | 

NKFPMATX(NKFT)  = NKFPMATX (NKFT>-NKFKGANX 

(NKFI+NKFH) *NKFPMATX (NKFS)  X 

END  I 

END  X 

FOR  NKFJ  (NKFI  BY  I WhluF.  NKFJ  <=  NKFSTANO)  t 
BEGIN  "UPDATE  COL  1 OR  2 OF" 

"COVAOI A-1CE  MAT" 

NKFS  = NKFCOLMN (NKF I ) *NKFJ  * 

NKFPMATX  (Ni\FS)  = NKFRMATXONKFKGANX  (NKFI  + NKF  J)  » 
FNO  X 

IF  NKFI  <>  0 » "X  UPDATE" 

BEGIN  "UPOATE  COL  1 FOR  Y UPDATE" 

NKFPMATX(O)  a NKFPMATX(0)-NKFP<)ATX<1)*NKFKGANX 
(1*0)  l 

FOR  NKF  j (2  BY  1 WHILE  NKFJ  <=  NKFSTANO)  X 
BEGIN 

NKFPMATX (NKFJ)  = NKF PMaT X ( NKF J ) -NKFKGANX 
( 1+NKFJ) « NKFPMATX ( 1 ) I 

END  X 

NKFPMATX (1)  = NKFKGANX (1 ♦ 0 ) *NKFRM*Tx  I 
END  ! 

f no  t 
RfTJHh  : 

fNn  » 


•i 

ii 

ii 


™ ^.agtaeslUM  li 
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FILE  C.PNHIT 


START 


COMPOOL (CPNOWNt 
CNDDATA. 
NHBMAST  » 
NRBAUX* 
NRBGNAV • 
cpnconsT)  i 
REF  PROC  C.PNPACK 


(S  "FIRST 
"PACKEO" 
(S  "FIXED 


•t 

•( 

•i 

H 

•I 

II 

II 

H 

II 

•I 


REF  PROC  C.PFXRCD 
DEF  PROC  C.PNHITO  I 
BEGIN 

"DEFINE  THE  SWITCH  NUmhER  BRANCH" 
SWITCH  cpnhrnch=( 
o:"hitcount, 

1 S"SLU» 

2I"SLU* 

3J"SLUt 
4«"SLU. 

5t"$LU» 
m"hitcount» 

7:"FLYT0» 

«I"ALTSELCT» 

RJ "DSPSELCT  » 

"10 J"STRHODE» 

"1 1 J"FASTHU, 

"12t"F0RWAH0. 

"13«"HEVERSE, 

"14!"FASTrEV, 

"15*"HlTCOUNTf 
"1AJ"ACCEPT» 

"17J"MEJECT» 

"185"ALTElEV, 

"1r:"automan. 

"20:"LAN0SEA, 

"21 :"INS1SEL, 

"2?: "INSIDIT  « 

"23:"INS2SEL* 

"2AI"TNS2oIT, 

"25  * "DE AOSLCT  « 

"26»"ADDHDRi 
"27 t "Hi TCOUNT  t 
’ 2H:"hITCOUNT. 

"29»"INS1EN8l» 

"30 J "INS2ENBL* 

"31 :"HlTCOUNT) J 
"DEFINF  alt/elev  ALT 
SWITCH  CPNAEBNs ( 

" 0J"ACM0AND5* 

" 1 t”ACHlAND2f 
" ?J"ACMUN02» 

" 33"ACM3, 

" A I " ACMA  t 
" 5J"ACH0AND5) » 

11*01'  Tu'CDf  MD  umif  uTTCH 


BYTE'SS  "NO.  BYTES")  B 32  » 
PT  VARBL'SS  "NO.  BYTES")  I 


CAL  MODE  BRANCH" 
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FILE 


C.PNHIT 


ANYHlTS  I IF  CPNHIT(O)  ■ 0 » 

RETURN  I 

ELSE  BEGIN  "OBTAIN  THE  NEXT  HIT" 
CPNTI1*CPNHIT{CPNHIT<0))  » 

CPNSWCH*CPNT11  « 

"is  the  new  status  off" 

IF  CPNTI1  < 0 1 

"IS  THE  HIT  A POSITION  SWITCH" 

IF  CPNTI1  < -2« 

OH  ICPNTI1  >=  “1A  ANO  CPNTIl  <s  -11) 
OH  CPNT 1 1 >*  -S  I 

CPNTI1=-CPNTI1  » 

ELSE  "IF  NOT.  IGnOkF" 

GOTO  HITCOUNT  » 

"NOW  BRANCH  ON  ThE  SWITCH  NUMBER" 

GOTO  CPNHHNCHtCPNTIl)  J 

flyto  i "if  the  fly  to  reguest  is  an  oap...  » 

IF  CMXTYPE (CPSXPTR)  = h I 

GOTO  HITCOUNT  I "IGNORE-  TllE  REQUEST" 
ELSE  BEGIN  "TURN  ON  TnE  ELY  TO  LIGHT" 

CPN0UTI3=CPN0UT 1 3 OR  KmaSK 1 9 f 
CPNFLYTO  = 1 ♦ "SET  FLYTO  FLAG" 
GOTO  ZEROCLOK  t 


ALTSELCT  ) 
SLU  S 

OSPSELCT  J 


STRMOOE  t 

FASTFWD  I 
FORWARD  I 


END  t 

"REVERSE  HSL  AND  HR  LIGHT  STATUS" 

ConOUT13'-*CPNOUT13  XOR  X'00006000»  « 
CPNHSL=CPN0UT13  AND  X«00006000«  » "SET  HSL/HR  FLAG" 
GOTO  ZEROCLOk  | 

'SET  RESET  INDICATED  SLU  STATUS  " 

CPN5LU (CPnT 1 1 ) aCPNSWCH  I 

GOTO  HITCOUNT  J 

"CYCLE  THE  LIGHT  TEMPLATE" 

CPNDIS=SHIFTl<CPnDIS»1>  » 

IF  CPNOIS  ANO  KMASK15  t 
CPNDIS  a KMASK19  I 

IF  CPNDIS  AND  KMASK17  I "IS  THE  NEW  MODE  NV" 

"STOP  THE  8LINK  TIMER" 

CPNDCLOK  = 0 » 

ELSE  "RE-START  THE  BLINK  TIMER" 

CPNUCLOK  a 1 » 

CPNOUT1A  s (CPNOUTU  AND  X»FFFFOFFF»)  OR  CPNDIS  I 
"LIGHT  APPROPRIATE  SEGMENT  AND  SET  THE" 

"MODE  FLAG" 

CPNDSLR  * SHIFTH (CPNDIS. 13)  J 
GOTO  7EROCLOK  » 

"REVERSE  STEER  MOOE  LIGHTS  AND  FLAG" 

CPNOUT 13  r.  CPNOUH3  XUR  X'OOOOOCOO'  I 

CPNSTRB  a SHIFTR  < CPNOUT ) 3 AND  X * 00000C00 * . 1 1 ) » 

GOTO  ZEROCLOK  » 

"SET  FWO/RtV  REQUEST  FLAG" 

CPNFWORV  a lo  I 
GOTO  FWDHVOfE  I 
CPNFWORV  a 1 | 

GOTO  KWORVOFE  I 


REVERSE  ! CPNFROPV  s -1  * 
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FILE  C.PNHIT 


1' 


I 


i 


I 


& 


I 

c 

T, 

< 

? 

r 

? 


i 


i 


FASTrEV  I 
FWOHVOFF  » 


ACCEPT  | 


REJECT  I 


ALTElEV  j 
ACMUND?: 

ACHA  « 


ACM3  1 


goto  fwohvoff  I 

CPNFWORV  * -10  « 

«IF  THE  NEW  STATUS  IS  OFF*  OR  IF  THE 
XHAIR  MOOE  TS  ID..." 

IF  CPnSWCh  < 0 OR  CPSIO  <>  0 ; 

CPNFwDWV  * 0 I “REMOVE  FWO/REV  REQUEST  FLAG" 

GOTO  ZEROCLOK  I 

“IGNORE  UNLESS  ALTITUDE  CALIBRATION" 

“MODE  IS  4“ 

IF  CPNACM  * 4 t 
HEGIN 

"SFT  ALT  CAL  COMPUTE  FLAG. AND  PREPARE 
TO  RECEIVE  KALMAN  VERDICTS" 

CPNACC  a CPNACS  » 

CPNACM  = 5 » 

NKFARJTM  s 0 t 
FKFARJTA  « 0 » 

ENU  t 

GOTO  HITCOUNT  » 

“IGNORE  IF  ALT  CAL  MODE  IS  S.  OTHERWISE" 

“ENO  ALT  CAL" 

IF  CPNACM  a S | 

GOTO  HITCOUNT  ( 

ELSE  HEGIN 

CPNOUT 14  a CPNOUT 14  AND  X FF9FFFF • t 
CPNOUT9  » CPNOUT9  OH  X»OI)FFFFFF»  I 
CPNACM  * 0 t 
CPNHAC  = 0 ; 

ENO  t 

GOTO  HITCOUNT  I 
"BRANCH  ON  ALT  CAL  MOOE" 

GOTO  CPNAEHN  (CPNACM)  » 

"TURN  OUT  ELFV  LIGHT .PULL  HIGH  ALT  CAL" 

"FLAG  DOWN" 

CPNOUT 14  * CPN0UT14  AND  KHMASK 1 3 ' I 
CPNHAC  « 0 * 

CPNACM  * 3 I 

IF  NCRALTOK  = 0?  "ARE  THE  RADAR  ALTIMETERS  DOWN" 

"IS  THE  FLH  UNAVAILABLE" 

IF  CPFLRON  = 0 I 

BEGIN  "TERMINATE  ALT  CAL" 

CPNOUT 9 * CPN0UT9  OR  X * OOFFFFFF  * l 
CPNOUT ) 4 = CPNOUT 1 4 AND  KRMASK 1 4 » 
CPNACM  r 0 I 

END  I 

ELSE  BEGIN  "SET  HIGH  ALT  CAL  FLAG  AND  ZERO 
THE  DELTA  BUFFER" 

CPNHAC  * 1 I 
CPNDELTA  « 0 J 
ENO  « 

GOTO  HITCOUNT  I 

"RECORD  WHICH  NAV  SYSTEM  WAS  USED  FOR" 

"ALT  CAl" 

CPNACS  « CPNNMS  I 

ONOUTi-1  = CPNOU T 1 4 OR  KMASK14  I "ADVANCE  TO  MODE  4" 


£ 

; 

\ 

*. 

I 


nz 


1 .jUVVif: 


FILE  C.PNHIT 


ACM0AND5  I 
AUTOMAN  t 


LANDSEA  J 


INS1SEL  t 


INSlOlT  t 


INS2SEL  I 
INS20IT  l 


deaoslct  : 
ADDROR  I 
INSlENBL  I 

TNS2ENBL  I 
ZEROCLOK  I 

..•  V/'mIUiV  • 

HI  i v-ywii  i « 


CPNACM  « 4 t 
GOTO  HITCOUNT  » 

••REVERSE  LIGHTS  AND  MODF.  INITIALIZE*' 

••SYSTEM  REQUEST" 

CRNOUT 14*CPN0UT  14  XOR  X'OCOOOOOO'  I 
CPNMANH«SHIFTR<CPN0UT14  AND  X'OCOOOOOO* .27)  » 
CPNNMSR=NCPRNV  5 
GOTO  HITCOUNT  » 

'•REVERSE  LANO/StA  MODE" 

CPNLANOH  s CPNLANDB  XuR  X *60000000 • » 

GOTO  HITCOUNT  I 
"REOUEST  INS1" 

CPNNMS  * 4 « 

GOTO  HITCOUNT  » 

••IF  IN  MANUAL  MODE.  CYCLE  LIGHT  AND 
TENTATIVE  REOUEST.  RESET  DISPLAY  CLOCK 
TO  ALLOW  ONt  SECOND  MODE  SET  DELAY" 

IF  CPNMAN  = 0 J 
BEGIN 

CPNMDIT*ShIFTL(CPNMDIT,1) J 
IF  CPNMOIT  AND  KMASK27  t 
CPNMDIT=KMASK31  I 
CPNOUT4=CPNOUT4  AND  X'FFFFFRFF* 

OH  SHIFTL  (CPNMDIT  »f»)  I 
CPNCLOCK-'l 3 I 

END  ( 

GOTO  HITCOUNT  t 
CPNNMS  * 2 . 

GOTO  HITCOUNT  » 

IF  CPNMAN*0  i 
BEGIN 

CRnaOIT  a SnlFTL (CRN AD IT . 1 ) t 

IF  CPNADIT  AND  KMASK27  I 
CPNADIT  = KMASn.31  » 

CRNOUTO  = CPNOUTO  AND  X ' F8FFFFFF ' 

OH  SHIFTLICPNADIT.24)  » 
CPNCLOCK  a 13  I 

END  » 

GOTO  HITCOUNT  T 

"SET  REOUEST  FLAG  TO  DEAD  RECKON" 

CPNNMS  * 1 I 
GOTO  HITCOUNT  J 

"REVERSE  OR/AODH  REQUEST  FLAG" 

CRNDDSR  ~ CPNDOSB  XOK  X»00000003'  I 
GOTO  HITCOUNT  ? 

"SET  INS  ENABLE  FLAG  TO  APPROPRIATE" 

"VALUE" 

CPNINS1  = CPNSWCM  * 

GOTO  HITCOUNT  I 
CPNINS2  = CPNSWCH  I 
GOTO  HITCOUNT  l 
"ALL  BRANCHES  RETURN  HERE" 

" SET  THE  DISPLAY  CLOCK  TO  ZERO  " 

CPNCLOCK  s 0 I 


! 
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FILE  CNDDATa 


ARRAY  CPNHIT  (7 

i 

S 31 

1 "THE  NAV  PROGRAM  HIT  TABLE" 

ITEM  CRSID  • 

S 

Jit 

"ID  MOOE  FLAG 

II 

ITEM  CPFL«ON 

s 

311 

"FORWARD  LOOKING  RADAR  ON 

It 

item  cmaltcal 

s 

31) 

"NEXT  DEST.  AN  ACT  CAL 

II 

item  cpkalicl 

s 

311 

"IKB  ALT  CAL  REQUEST 

II 

item  CPKTNFIV 

F 

t 

"1KW  TERRAIN  ELEVATION 

M 

item  cpsnujo 

s 

31 1 

"POSITION  UPDATE  IN  PROGRESS 

It 

item  CnrsTp 

s 

31 1 

"STEER  POINT  FLAG 

II 

item  CMCSPlt) 

c. 

311 

"STEER  POINT  TYPE 

II 

ITEM  CMCSPSN  S 

31  1 "STEER  PT.  SEN.  NO." 

item  CAFFOTF 

p 

321 

"FLT  DR  ENGD/AUTO  TF  FLAG 

H 

ITEM  CAFSHOOf 

H 

32 1 

"FLIGHT  DIRECTOR  MODE 

II 

ARRAY  CPH<'0(7> 

H 

321 

"BCD  ARRAY 

II 

ARRAY  CMXLAT 

<7>  F 

1 

ARRAY  CMXLONG 

(7)  F 

1 

ARRAY  CMXELEV 

(7)  F 

1 

ARRAY  CMXOUAL 

( 7)  S 

311 

ARRAY  CMXSQnO 

(7)  S 

31 1 

ARRAY  CMXTYPE 

(71  S 

311 

item  cpsxptr 

s 

31 1 

"POINTER  INTO  CMXHAIR 

II 

ITEM  NCRALTOk 

s 

311 

"RADAR  ALTITUDE  OK  » 

item  ncpalt 

F 

t 

"RADAR  ALTITUDE. FEET" 

item  NCALTp 

F 

1 

"PRIME  ALTITUOE.fi." 

item  nsitg 

F 

I 

"TIME  TO  DESTINATION. SEC" 

item  nsrng 

F 

t 

"RANGt  TO  DESTINATION" 

item  NLAT 

F 

1 

"DISPLAY  LAT. RADIANS" 

item  nlong 

F 

t 

"OISPLAY  LONG.  RADIANS" 

ITEM  NVGND 

F 

1 

"DISPLAY  GND  SPEED. FT/SEC" 

ITEM  NHGT 

F 

( 

"GROUND  TRACK. RADIANS" 

ITFm  NTHEAG 

F 

1 

"TRUE  HEADING. RADIANS" 

ITEM  NwhEAD 

F 

1 

"WIND  HEADING. RADI ANS" 

ITEM  NWIND 

F 

1 

"WIND  SPEED.  FT/SEC  « 

ITEM  NhDISP 

F 

I 

"HEIGHT  AMOVE  SEA  LEVEL.FT" 

item  normoof 

S 

31 1 

"OEAD  RECKON  MODE  » 

ITEM  NCOOPCUT 

s 

31] 

"DOPPLER  CUT-OUT  FLAG  " 

item  ncaalcqt 

s 

311 

"INS2  UP" 

ITEM  NCMALCPT 

s 

311 

"INS1  UP" 

ITEM  nvfstrt 

s 

Jll 

"DEAD  RECKON  RESTART  FLAG" 

ITEM  NKFAPjTM 

s 

31 1 

"INS1  ALT  CAL  REJECT  FLAG" 

item  nkfahjta 

s 

311 

"INS2  ALT  CAL  REJECT  FLAG" 

ITEM  NCAVAIIM 

B 

321 

"INS1  DIT  AVAILABLE  FLAG" 

ITEM  NCAVAILA 

B 

321 

"INS2  DU  AVAILABLE  FLAG  " 

ITEM  NCMDIT 

R 

321 

item  ncadit 

B 

321 

ITEM  NCPRNV 

H 

lb  1 

"PRIME  SYSTEM  FLAG" 

GOTO 

ANYHITS 

1 

END  1 

END  1 "OF  HIT  PHOCEOURE  DEFINITION'' 

TERM 
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CPNOWN 


ITEM  CpnmTjmf 
ITEM  CpnTImm 
ITEM  CPNCLOCK 
ITEM  CPNCLOkR 
ITEM  CPNHSL 
ITEM  CPNOCLOK 
ITEM  CPNDI5 
ITEM  CPNACm 
ITEM  CPNMOIT 
ITEM  CpnaUIT 
ITEM  CPMTI1 
item  cpnthi 
item  CPNTF1 
ITEM  CPNT I ?. 
ITEM  CPNTB? 
ITEM  CPNTF? 


S 31  I "MISSION  TIME  IN  MAJOP  FRAMES" 

H 32  » "PIT  NAMP  FOR  MISSION  TiMt  » 

S 31  * "DISPLAY  CLOCK — A KOO  16  COUNTER" 
8 32  I "BIT  NAME  FOR  THE  OISMLAY  CLOCK" 

B 32  I "HR/MSL  FLA6" 

S 31  I "DISPLAY  SELECT  BLINK  TIMER" 

H 32  I "DISPLAY  SELECT  TEMPLATE" 

S 31  I "ALT  CAL  MODE  " 

8 32  « "TNS1  PIT  RFOUEST  FLAG" 

8 32  I "INS2  01 T REOUEST  Ft.AG» 

S 31  I "TEMPI" 

B 32  I "TEMPI" 

F I "TEMPI" 

S 31  » "TEMP?" 

B 32  I "TEMP?" 

F I "TEMP?" 


"VARIAPLFS  LOCAL  TO  C.PNHIT 


ITEM  CPNSWCH 
ITEM  CpmaCS 


"Data  local  to  c.pndisd" 


'•ACTIVE  HIT  SWITCH  NO. /STATUS" 
'•NAV  SYSTEM  USED  FOR  AlT  CAL  " 


ITEM  CPMPPDOK  S 31 t "PPESENT  POSITION  DATA  OK  FlA6 
ITEM  CPNSKlMO  S 31 1 "SELECT EO  PT . SEO  NO. 

ITEM  CPNUPM.i  H 35 1 "UPDATE  REJECT  LIGhT  TEMPLATE 
ITEM  CPNMAfil  S 31 1 "SPLE CTEO  POINT  MAGWHEFL  TIMER 

ITEM  CPMSLTYP  8 32;"SELECTEU  POINT  TYPE 

ITEM  CPNTNKl  V F l"TERRAIN  E.LEV..FEET 

item  cpmselom  e i "Selected  point  long  *raoi ans 

item  CPNSELAT  F I"SFlECTEO  point  lat  .radians 

ITEM  CPNSLFLV  F l"SELECTE0  point  elev.feft 

ITEM  CPNSThno  s 311 "STFEM  POINT  SEO  NO. 

IT-v,  CPNMAG?  S 31»"STFER  point  magwheel  TIMER 

ITEM  CPNSTTYP  S 31 1 "STEER  POINT  TYPE 

ARRAY  CPNSLPOS(l)  FI"SFLECTED  POINT  POSITION 
ARRAY  CPNTAP  (1)  FI "TIME  AND  RANGE  TO  SELECTED  PT 
ARRAY  CPNMCODE (9)  B 32l 

"THE  FOLLOWImG  ARE  H 32  NAMES  FOR  THE  ABOVE 
OUTPUTS  TO  The  PANEL" 

TO  8 32  t 


ITEM  CPNOUTO  8 32  t 

ITEM  CPNOUTJ  B 32  I 

ITEM  CPN0UT2  B 32  » 

ITEM  CPN0UT3  B 32  I 

ITEM  CPNOUT*  B 32  » 

ITEM  CPNOUTS  8 32  * 

ITFM  CPN0UT6  3 32  » 

ITEM  CPN0UT7  B 32  I 

1 1 Em  CPNOUTh  8 32  » 

ITEM  CPNOUTQ  B 32  I 

ITEM  CPNOUT in  B 32  I 

ITEM  CPNOUTn  B 32  I 

ITEM  CPN0UT1?  B 32  I 

ITEM  CPNOUT 1 3 8 32  » 

ITEM  CPNOUT 1 4 B 32  I 

ITEM  CPNOUT IS  B 32  » " " 

"The  following  is  an  apray  name  for  the 
OUTPUT  Tf)  ThF  PANELS" 


B 32  I 
B 32  I 
8 32  * 
3 32  » 
B 32  » 
8 32  » 
B 32  I 
B 32  I 
B 32  I 
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FILE 


CFNOWN 


ARRAY  CPNOUTa ( 15)  B 32  I " " 


“The 

FOLLOWING 

varibles 

are  REFERENCED  BY  other  PROGRAMS" 

item 

cpnstefr 

s 

ill 

“STEER  MODE  0— TRK  l— D!« 

II 

ITEM 

CPnSTrr 

B 

321 

“HIT  NAME  FOR  STEER  MODE 

H 

ITEM 

CRNFwORV 

s 

3n 

“FORWARD  REVERSE  REQUEST 

•t 

ITEM 

CPNROLl 

s 

311 

“FORWARD  REVERSE  COMMAND 

If 

ITEM 

CPMACC 

s 

311 

“alt  cal  compute 

M 

ITEM 

CPNHAC 

s 

31  * 

“WIGS  ALT  CAL  REQUEST 

II 

ITEM 

Cpnman 

s 

311 

“AUTO/MAN  mode  flag 

II 

ITEM 

CPNMANR 

B 

321 

“HIT  NAME  FOR  AUTO/MAN  FLAG 

II 

ITEM 

cpnlano 

S 

ill 

“LANU/SEA  flag 

II 

ITEM 

CPNL  ANOB 

H 

321 

“HIT  NAME  FOR  LaND/SEA  FLAG 

II 

ITEM 

CPNNMS 

s 

ill 

“NAV  SYSTEM  SELECT 

II 

ITEM 

CPNNMSR 

B 

321 

“HIT  NAME  FOR  NmS 

II 

ITEM 

CPNDOS 

s 

Jit 

“OR/ADDR  REQUEST 

’! 

ITEM 

CPNOOSR 

B 

321 

“HIT  Name  FOR  or/ador 

It 

ITEM 

CPNINS1 

c 

311 

“INS1  ENABLE/OISABLE 

II 

ITEM 

CPNINS2 

S 

ill 

“INS2  ENABLE/OISAHLE 

If 

ITEM 

CPNSLUA 

S 

311 

“AFT 

II 

ITEM 

CPNSIWL 

1 

311 

“LEFT  PYLON 

II 

ITEM 

CPNSLUR 

S 

311 

“RIGHT  PYLON  SLU  ENABLE 

It 

item 

CPNSLU! 

s 

311 

“INTRMJ) 

to 

ITEM 

CPNSLUF 

s 

311 

“FORWARD 

•1 

ITEM 

CPNDELTF 

F 

I 

“ALT  CAL  DELTA  BUFFER 

to 

array  CRNSLIM5) 

s 

1 31  I 

“THIS  IS  THE  SLU  STATUS  TABLE. 
IT  IS  •OVERLAYED*  WITH  THE  SLU 
STATUS  WORDS  ABOVE" 

item 

CPNKLYTO 

s 

311 

“FLY  TO  FLAG 

•1 

item 

CPNOSL 

s 

311 

“OISpaly  select  flag 

II 

ITEM 

CPNOSLR 

B 

321 

“HIT  NAME  FOR  CPNOS? 

II 

"OVFRLAY  DECLARATIONS  FOR  CPNOwN" 


OVERLAY 

CPNSTEFR 

•CPNSTRR 

1 

OVERLAY 

Cpnman 

aCPNMANH 

I 

overlay 

CPNLANO 

■CPNLANOR 

1 

OVERLAY 

CPNNMS 

•CPNNMSH 

I 

OVERLAY 

CPnDOS 

•CPNDOSM 

1 

OVERLAY 

cpnslu 

•CPNSLUA t 

CPNSLUL* 

cpnslur. 

CPNSLU 1» 
CPNSLUF  1 

OVERLAY 

CPNMTJME 

•CPNTIMH 

1 

OVERLAY 

CPNCLOCK 

•CPNCLOKB 1 

ovf»lay 

CPnTII 

•CPNTF1 

* 

overlay 

CPnT 1 2 

■CPNTB2 

S' 

OVERLAY 

CpnDSl 

■CPNDSLB 

I 

CPNTBl  I 
CPNTF2  I 


316 


‘ • V*v*.  4.  'Vlx 


/?• H -h*  *7> 


file  nrrmast 


ITEM 

nilatm 

F 

1 

•'LATITUOE(RADIANS)" 

ITFM 

NILONm 

F 

"LONGITUDE (RADI ANS) " 

ITEM 

NIALTm 

F 

< 

"ALTITUDE (FEET)" 

ITEM 

NIVNM 

F 

1 

"VELOCITY  NORTh(FVSFC)" 

ITEM 

NIVEM 

F 

5 

"VELOCITY  EAST (FT/SEC) " 

ITEM 

NIHDOTm 

F 

I 

"ALTITUDE  "ATE (FT/SEC)" 

ITFM 

NTPSITm 

F 

1 

"TRUE  HEADINO(PADIANS)" 

ITEM 

NfPS I MM 

F 

1 

"MAGNETIC  HEADING (RADIANS) " 

ITEM 

ntgravm 

F 

1 

"LOCAL  GRAVITY (FT/SEC**2)" 

ITEM 

HCMPITC 

F 

t 

"P I TCH (R ADI ANS* " 

ITEM 

ncmroll 

F 

t 

"ROLL (RADIANS)" 

ITEM 

ncmyaw 

F 

I 

"YAW  (RADIANS)  •’ 

ITEM 

NCMPUOT 

F 

1 

"P  CH  RATE (RAD/SEC)" 

ITEM 

NCMRDOT 

F 

« 

"ROLL  RATE (RAD/SEC)" 

ITEM 

•i 

NCMYDOT 

F 

1 

"YAW  RATE (RAD/SEC) " 

" navigation  data  common  to  master  AND  AUXILIARY  •• 

•I  II 


ITEM  NIALFam 

item  ntvxm 

ITEM  NIVYM 

ite<<  nivzm 

ITEM  NCMAX 
item  NCMAY 
item  ncmaZ 
item  niovaxm 

ITEM  NIOVAYM 

item  MTDVAZM 
ITEM  NTC12M 
ITEM  NIC22M 
ITEM  Nir'igM 
ITEM  NTC13M 
ITEM  NTC23M 
ITEM  NIC33M 
ITEM  NTC120M 
ITEM  NIC220M 
ITEM  NIC32DM 
ITEM  NIC130M 
ITEM  NIC230H 
ITEM  NIC330M 
ITEM  NIOMEGXm 

itfm  niomegym 

ITEM  NI0MEG7M 
ITEM  NIRHOXm 
ITEM  NIRHOYm 
item  NJPRXm 
item  NIPRYm 
item  NTAXCM 
ITEM  NIAYCm 
ITEM  NIAZCm 
item  NIOAXCM 
ITEM  NIOAYCW 
ITEM  NiOAcCM 
ii 


F I "WANDER  ANGLE (RADIANS) " 

F ? "X  PLATFORM  VELOClTY(FT/SEC)» 
f i "Y  platform  velocity (Ft/sec>» 

F I "Z  PLATFORM  VtLOCI TY ( FT/StC) " 

F » "X  ACCELEROMETER(FT/SEC/FRAME)" 

F t «Y  ACCELEROMETER (FT/SEC/FRAME)" 

F I «Z  ACCELEROMETER (FT/SEC/FHAME)" 

F I "DELTA  X VELOCITY(FT/SEC/FRAME>» 

F » "DELTA  Y VELOCITY (FT/SFC/FRaME) " 

F I "OFLTA  Z VELOCITY (FT/SEC/FRAME)" 

F I "DIRECTION  COSINE  C(l»2)" 

F » "DIRECTION  COSINE  C(2*?>» 

F » "DIRECTION  COSINF  C(3*2)" 

F » "DIRECTION  COSINE  C(1.3)" 

F I • DIRECT  ION  COSINE  C<2*3)" 

F I "DIRECTION  COSINE  C ! 3 ♦ 3 ) *' 

F * "DERIVATIVE  OF  C(l*2)» 

F I "DERIVATIVE  OF  C(2.2>" 

F I "DERIVATIVF  OF  C (3*2) " 

F I "DERIVATIVE  OF  C(Ii3)" 

F I "DERIVATIVE  OF  C(2*3)" 

F » "DERIVATIVF  OF  C<3*3>» 

F I "EARTH  KATE  ABOUT  X(RAO/SEC)" 

F I "EARTH  HATE  ABOUT  Y (PAD/SEC)" 

F ) "EARTH  RATE  ABOUT  Z (RAU/SEC) « 

F » "CRAFT  RATE  ABOUT  X (RAD/SEC)" 

F I "CRAFT  RATE  ABOUT  Y (RAD/SEC)" 

F » "PLATFORM  RATE  ABOUT  X(PAO/SfC)« 

F I "PLATFORM  RATE  ABOUT  Y(RAD/5FC)" 

F » "CORRECTED  X ACCEUFT/SEC/FRAME ) " 
F * "CORRECTED  Y ACCEL  (F  T /SFC/FRAMF.)  " 
F I "CORRECTED  L ACCEUFT/SEC/FRAME)" 
F « "X  ACCEL  NOISE  EST (FT/SEC/T RAME ) " 
F I "Y  ACCEL  NOISE  EST (FT/SEC/FRAME) " 

5 * ;»7  ±f’r%Pi  H » AO  r^?  / r T 'rr/*/CniMCUi 


M 


It 


KALMAN  FILTER  DATA 


FILE  NRflMAST 


ITEM  NKFPRJTM  F I 
ARRAY  NAINSM{  50)  F‘» 
HEM  NKP0101M  F I 
ITEM  NKR0201M  F I 
ARRAY  NKFPMATM(189)F  » 
ARRAY  MKXHATM(lH)  F I 
ARRAY  NKYMSVM(A)  F I 


"POSITION  FIX  REJECT  FLAG" 

"COVARIANCE  ELEMENT  P(l.ll" 
"COVARIANCE  ELEMENT  P J?.l)" 
"INS  l COVARIANCE  MATRIX" 
"INS  1 STATE  VECTOR" 

•INS  1 MEASUREMENT  VECTOR" 


I 

I 


318 


FILE 


NRRAUX 


ITCm 

NILAT  a 

F 

1 

ITFm 

NTLONa 

F 

ITEM 

NIALTa 

F 

1 

ITEm 

NJVNA 

F 

1 

ITEM 

ntvea 

F 

1 

ITEm 

NTHDOTa 

F 

1 

ITEM 

NtPSITi 

F 

t 

ITF.m 

NIPSIma 

F 

t 

item 

NIGRAVA 

F 

1 

ITE’m 

NCAPITCh 

F 

1 

iter 

ncaroll 

F 

1 

ITEM 

NC AY  AW 

F 

» 

ITEr 

NCAPOOT 

F 

» 

item 

ncardot 

F 

t 

item 

II 

ncaydot 

F 

1 

" NAVIGATION  data  COMMO 
■1 

ITEM 

NIALFAA 

F 

I 

ITFM 

NIVXA 

F 

< 

item 

NTVYA 

F 

t 

item 

NIVZA 

F 

t 

ITFm 

NCAAX 

F 

I 

ITEM 

ncaay 

F 

1 

ITEM 

ncaaz 

F 

t 

ITEm 

NJDVAXa 

F 

1 

ITFm 

NjnVAYA 

F 

» 

ITEM 

nidvaza 

F 

1 

ITEm 

NTC12A 

F 

1 

item 

NIC22A 

F 

t 

ITEm 

NIC32A 

F 

« 

ITEm 

NTCl 3A 

F 

1 

ITEM 

NTC23A 

F 

» 

ITEM 

NIC33A 

F 

1 

ITEM 

NTC120A 

F 

1 

ITEM 

NIC22DA 

K 

» 

ITEM 

NTC32DA 

F 

« 

ITEm 

NIC13DA 

F 

1 

ITEM 

NIC23DA 

F 

t 

ITEM 

NTC33DA 

F 

1 

ITF.m 

ntomegxa 

F 

1 

ITEM 

ntomegya 

F 

t 

ITEM 

ntomegza 

F 

1 

item 

NTRHOXa 

F 

1 

ITEM 

NTRHOYA 

F 

1 

ITEM 

NIPRXa 

F 

1 

ITEM 

nippya 

F 

1 

ITEM 

NT  aXCa 

F 

1 

ITFm 

NT  AYCA 

F 

« 

ITEM 

NT  AZCA 

F 

( 

ITEM 

NTDAXCA 

F 

1 

ITEM 

nidayca 

F 

* 

item 

19 

ntdaZca 

F 

1 

tl 

KALMAN 

FILTER 

"LATITUOF(RAOIANS)" 

"LONG I TUOE (RADIANS) " 

"AL  r I TUDE  (FEET ) " 

"VFLOCITY  NORTh(FT/SEC) " 
"VELOCITY  EAST (FT/SEC)" 

"ALTITUDE  HATE(FT/SEC>" 

"TRUE  HEADING(RAOIANS)" 

"MAGNETIC  HEADING (RADIANS)" 

;,LOC Al  GRAVITY  (TT/SEC**  >" 

*’RT  TCH  (RADI  ANS)  " 

"ROLL (RADIANS)" 

"YAW (RADIANS) " 

"PITCH  RATE (RAD/SEC) " 

"ROLL  HATE (RAD/SEC)" 

"YAW  RATE (PAD/SEC)" 

II 

M TO  MASTER  AND  AUXILIARY  " 

ii 

"WANDER  ANGLE (RADI ANS) " 

"X  PLATFORM  VELOCITY (FT/SEC) " 

"Y  PLATFORM  VELOClTY(FT/SEC)" 

"Z  PLATFORM  VELOCITY (PT/SEC) " 

"X  ACCElEROMFTER (FT/SEC/FRAMF) » 
"Y  ACCELEHOMETtK( FT/SEC/FRAME)" 
"Z  ACCELEROMETER (FT/SEC/FRAME)" 
"DELTA  X VELOCITY (FT/SEC/FRAME)" 
"DELTA  Y VFLOCITY (FT/SEC/KRAME) » 
"DELTA  Z VELOClTY(FT/SEC/FRAME)» 
"DIRECTION  COSINE  C(l*2)» 

COSINE 
COSINF. 

COSINE 
COSINE 
COSINE 
OF 
OF 


C (2*2)  " 
C(3.?>" 
C ( 1 * 3 ) " 
C(2.3)» 
C ( 3 » 3 ) " 
C ( 1 *2)  " 

C (2*2)  " 


"DIRECTION 
"DIRECTION 
"DIHECTTON 
"DIRECTION 
••u;.:LuTion 
"DFRIVATIVE 
"DFRIVAT1VF 
"DERIVATIVE  OF  C ( 3.2) » 

"DERIVATIVE  OK  C ( 1 . 3 ) " 

"DERIVATIVE  OF  C(2*3)" 

"DERIVATIVE  OF  C ( 3. 3) » 

"EARTH  RATE  ABOUT  X (RAD/SEC)" 
"EARTH  RATF  ABOUT  Y (RAD/SEC) » 
"EARTH  HATE  ABOUT  Z (RAD/SEC)" 
"CRAFT  RATF  ABOUT  X (RAD/SEC) " 
"CRAFT  RATE  ABOUT  Y (RAD/SEC)" 
"PLATFORM  PATt  ABOUT  X (HAD/SEC) » 
"PLATFOHM  PATE  ABOUT  Y(RaD/SFC)" 
"CORKF.CTFD  X ACCKL  (FT/SEC/FRAME  ) " 
"CORRECTED  Y ACCEL  (FT/SF C/FRA ME ) " 
"CORRECTED  Z ACCEL (FT/SEC/f RAME) " 
"X  ACCtL  NOISE  FST (FT/SEC/FRAME)" 
"Y  ACCEL  NOISE  EST  (FT/SF.C/FPAME)  " 
"Z  ACCEL  BIAS  EST (FT/SEC/FRAHE) " 

ii 

DATA  " 
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FILE  NRBAUX 


ITEM  NKFPRJTA 
ARRAY  NA I NS A ( SO) 
ITEM  NKPOlOU 
ITEM  NKP0201A 
ARRAY  NKFPMATAU8 
ARRAY  NKXHATA(lH) 
ARRAY  NKYMSVA < A ) 


t 

» 

I 

I 

% 

t 


“POSITION  FIX  REJECT  FLAG*' 

••COVARIANCE  ELEMENT  P(l»l>" 
••COVARIANCE  ELEMENT  P(2.1)“ 
••COVARIANCE  MATRIX  ARRAY*' 
••STATE  VECTOR  •• 

••MEASUREMENT  VECTOR" 


ft 


I 


I 


K 
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nrrgnav 


ITEM  NkfTMPI  f i • 

ITEM  NKFTMP2  F * 

ITEM  NKFTHP3  F * 

ITEM  MXFNUSET  S 31  I 
item  NrrPPwL  B 32  * 
ITEM  NKFl  S 31  I 
ITEM  NkF  J S 31  » 

ITEM  NKFM  S 31  I 
I7FM  NKFS  S 31  * 

ITFM  NKFT  S 31  * 

ITFM  NKFKGO  F I 
ITEM  NkFSTaNO  S 31  I 

item  NKFHMATX  F I 

ITEM  NKFAN  F » 

ITEM  NKFAE  F » 

ITEM  NKFEX  F 1 
ITEM  NKFEV  F * 

ITEM  MCPBIME  S 31  I 
ITEM  CSwPDN  F ( 

ITEM  CSNPUE  F t 
ITEM  NCI  ATP  F I 
ITEM  NClONP  F t 
ITEM  NLATC  F I 

ITEM  NI.ONC  F I 

ITEM  CMFPHUAL  S 31  1 
ITFM  NOALT  F I 

ARRAY  NKFKGAIN (38) F » 
ARRAY  NKfCOLMN(  IP)  S 
ARRAY  KRPMATA  ( 2>F  I 
ARRAY  NkINIT?  ( 1«)F 
ITFM  KMTNE  F « 

ITEM  KERADIUS  F ) 

ITFM  KPFLTaT  F I 

ITEM  KRPAVO  F » 

ITEM  kgpavi  f I 

ITEM  KGRAV2  F t 

ITEM  KELPTCTY  F » 

ITEM  K2FOHF  F I 

ITEM  KIORE  F 5 

ITEM  KFAHTHR  F I 

ITEM  KNKl  F I 

ITFM  KNK2  F 1 

ITEM  KONE  F * 


"TcriPoWAftV  STORAGE" 

'••TEMPORARY  STORAGE" 

"TEMPORARY  STOWAGE" 

"NAV  TABLE  DATA  INDEX" 

"POSITION  FIX  TYPE  TLAG” 

"LOOP  INDEX" 

"LOOP  INDEX" 

"LOOP  INDEX" 

"SUBSCRIPT" 

"SUBSCRIPT" 

"DENOMIN.'T  OF  KALMAN  GAIN" 
"ELEMENTS  IN  STATF  VECTOR" 

"LESS  1" 

"POSITION  MEASUREMENT" 

"NOISE (FT**2) " 

"NORTH  COMPONENT  OF  POS" 

"ERROR (FT)" 

"EAST  COMPONENT  OF  POS" 

' "ERROP (FT ) " 

"X  TEPM  IN  POS  TEST" 

"Y  TERM  IN  POS  TEST" 

"Prime  oata  flag*1 

"NORTH  POS  ERROR (FT)" 

"EAST  POS  ERROR (Ff)" 

"PRIME  LATITUUF (RADIANS)" 
"PRIME  LONGITUOF(PADIANS)" 
"OVERFLY  CHECKPOINT" 

"LATITUDE (RAD) " 

"OVERFLY  CHECKPOINT" 

"LONGITUDE (RAD) " 

••checkpoint  duality  indfx« 
"DEAD  RECKONING  ALTITUDE" 
"KALMAN  GAIN  MATRIX" 

31  1 "SYMMETRIC  MATRIX  POINTERS" 
"POSITION  NOISE (FT*«2i" 

I "ZNIT  VALUE  OF  COV  FATRIX" 
"POITION  TEST  CONST" 

"Earth  rad  at  eouatoR(FT)" 
"FRAMF  TIME (SEC)" 
"GRAVITATIONAL  CONSTANT" 
"GRAVITATIONAL  CONSTANT" 
"GRAVITATIONAL  CONSTANT" 
"EARTH  ELLIPTICITY  » 
"?»KELPTCTY/KERADIU3" 
"1/KERAOIUS" 

"EARTH  RATE (RAO/SEC)" 
"INERTIAL  CONSTANT" 

"1NF.RTIAL  CONSTANT" 

"ONE" 
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e 


file 


V 


K 


t 


CPNCONST 


constant 

KMaSKO 

B 

32 

3 

X'UOOOOOOO 

constant 

KmaSKI 

B 

32 

* 

X * 40000000 

constant 

KmaSK? 

6 

32 

3 

X * 20000000 

constant 

kmaSK  3 

B 

32 

s 

X’10000000 

constant 

KMASK4 

B 

32 

z 

X • 08000000 

constant 

KMASKS 

B 

.32 

X 

X • 04000000 

constant 

K«ASK6 

B 

32 

3 

X • 02000000 

constant 

KMASK7 

B 

32 

s 

X'UIOOOOOO 

constant 

KMASKA 

B 

32 

r 

X»00300000 

constant 

KMASKI 

B 

32 

3 

X* 00400000 

constant 

KMASK10 

B 

32 

= 

X • 00200000 

constant 

KmaSMI 

B 

32 

= 

X'00100000 

CONSTANT 

KMASK 12 

B 

32 

= 

X • 00080000 

CONSTANT 

KmaSK 1 3 

B 

32 

= 

X '00040000 

constant 

KMASK 1 A 

B 

32 

s 

X • 00020000 

constant 

KMASK1S 

B 

32 

3 

X'00010000 

constant 

KMASK 1 6 

B 

32 

3 

X • 00008000 

constant 

KMASK 17 

B 

32 

r 

X • 00004000 

constant 

kmask i s 

B 

32 

s 

X ' 00002000 

constant 

KmaSK 1 9 

B 

32 

X 

X'00001000 

constant 

KMASK20 

B 

32 

T. 

X • OOOOOROO 

constant 

KMASK21 

B 

32 

X 

X»00000400 

CONSTANT 

KMASK22 

B 

32 

3 

X ' 00000200 

constant 

K«aSK23 

B 

32 

3 

X'OOOOUlOO 

constant 

KmaSK  ?4 

a 

3? 

3 

X'OOOOOOrtO 

constant 

KmaSk 25 

B 

32 

3 

X'00000040 

constant 

KMASK26 

B 

32 

3 

X * 00000020 

constant 

Kmask  ?7 

8 

32 

3 

X'00000010 

constant 

KMASK28 

8 

32 

3 

X • 00000008 

constant 

KMASK29 

a 

32 

3 

X'00000004 

constant 

KMASK30 

B 

32 

3 

X • 00000002 

constant 

KMASK31 

a 

32 

3 

X' 00000001 

constant 

KHMASKO 

B 

32 

3 

X • 7FFFFFFF 

constant 

KRmaSKI 

B 

32 

X 

X'BFFFFFFF 

constant 

KRmaSK? 

B 

32 

3 

x • dfffffff 

constant 

KRMASK3 

B 

32 

S 

X'EFFFFFFF 

constant 

KRmaSKA 

B 

32 

3 

X • F7FFFFFF 

constant 

KRmaSKS 

B 

32 

3 

X'FBFFFFFF 

constant 

KRMASKf. 

B 

32 

3 

X'FOFFFFFF 

constant 

KRmaSK  7 

B 

32 

3 

X * "EFFFFFF 

constant 

KRmaSKH 

B 

32 

3 

X ' Ff 7FFFFF 

constant 

KRMaSKR 

B 

32 

3 

X ' FFhFFFFF 

constant 

KRmaSK 10 

B 

32 

3 

X ' FFDFFFFF 

constant 

KRM/.SK1  1 

B 

32 

3 

X'FFEFFFFF 

constant 

KRmaSK 12 

B 

32 

3 

X • FFF7FFFF 

constant 

KRmaSK 13 

B 

32 

X 

X • FFFRFFFF 

constant 

KRmaSKH 

B 

32 

E 

X • FFFOFFFF 

constant 

KRmaSK 15 

B 

32 

3 

X • FFFFFFFF 

constant 

KPmaSK 16 

B 

32 

3 

X'FFFFTFFF 

constant 

KRmaSK 1 7 

H 

3? 

3 

* t ffffhfff 

constant 

KRMASK 1 8 

B 

32 

3 

X * KFFFOFFF 

constant 

KRMASK 19 

8 

32 

r 

X * FFFFEFFF 

constant 

KRMASK20 

e 

32 

c 

X ' FFFFK7FF 
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CPNCONST 


constant 

KK-.ftSKPl 

B 

32 

a 

X * FFFFFBFF ' 

* ! 

constant 

KRm&SK?2 

ft 

32 

a 

X*FFFFFOFF» 

» I 

constant 

KRm/jSk?3 

B 

32 

a 

X'FFFFFEFF' 

t ! 

constant 

KHMASK2* 

B 

32 

a 

X*FFFFFF7F* 

» ! 

CONSTANT 

KWMASKPS 

B 

3? 

a 

X»FFFFFFBF* 

» 1 

CONSTANT 

KWM4SK26 

B 

32 

a 

X'FFFFFFOF* 

1 ! 

CONSTANT 

KRmaSK?7 

B 

32 

a 

X«FFFFFFEF« 

CONSTANT 

KWM4SX28 

B 

32 

a 

X ' FFFFFFF7  * 

constant 

KRMASK29 

B 

32 

a 

X'FKFFFFFB* 

1 

constant 

KHMASK30 

e 

32 

a 

X*FTFFFFFO* 

1 

constant 

KRMASK31 

b 

32 

a 

x»fffffffe* 

1 

f 

f 

4' 


t 

t 

i 


I 


I 

t 


\ 
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-Ham., 


K 


3.  Programs  and  Data  Files  for  ASP  Version  of  Teata 
n.kFnup  aed 

BFGIN 

•INSERT  NRHGNAV  I 

II.  POSITION  UPDATE  PROGRAM 

DEFINE  PROCEOURE  N.KFNUP (NkFPMATX .NKFKGANX) 

III  definition  of  formal  parameters 


where  BEAL  ARRAY  NKFPMATX  » 
REAL  ARRAY  NKFKGANX  5 


• • • 
• • • 


//  * 
// 
// 

// 
// 
// 

...  covariance  matrix  array  // 

...  KALMAN  GAIN  ARRAY  // 

// 

entry  to  position  update  program  //  ■ 

...  // 

TORE  begin 

FOB  NKFI  a O'  STEP  1 WHILE  NKFI  <=  1 ...  X AND  Y UPDATE  // 
DO  BEGIN 

NKFS  = NKFCOLMN (NKFI) *NKF I » 

NKFKGD  3 NKFPMAfX (NKFS) ♦NKFRHaTX  5 

FOR  NKFj  s NKFI  STEP  1 WHILF  NKFJ  <=  NKFSTANO 

00  BEGIN  ...  CALCULATE  KALMAN  GAIN  // 

NKFS  a NKFCOLMN (NKFJ) *NKFI  I 

NKFKGANX (NKF I ♦ NKFJ)  = MKFPMATX (NKFS) /NKFKGD  » 

END  I 

IF  NKFI  ==  1 ...  KALMAN  GAIN  FOR  Y UPDATE  // 

THEN  NKFKGANX (1*0)  = NKF PHAT X ( 1 ) /NKFKGD  I 
FOR  NKFj  = NKFI*1  STEP  1 WHILE  NkFJ  <=  NKFSTANO 
00  BEGIN  ...  UPDATF  COVARIANCE  MATRIX  // 

NKFS  = NKFCOLMN (NKFI) »NKF J V 

FOR  NKFH  s NKFJ  STEP  1 WHILE  NKFH  <s  NkFSTanO 
DO  BEGIN 

NKFT  = NKFCOLMN (NKFJ).NKFH  » 

NKFPMATX (NKFT)  3 NKFPMATX (NKFT) -NKFKGANX 
(NKFI*NKFH)*NKFPMATX(NKFS)  I 
END  » 

ENn  » 

FOR  NKF, | a NKFI  STEP  1 WHILE  NKFJ  <s  mkFSTANO 
00  BEGIN  ...  UPDATE  COL  ) OK  ? OF 

COVARIANCE  MAT  // 

NKFS  * NKFCOLMN (NKFI) *NKF J I 

NKFPMATX(NKFS)  = NKFRMATX<*NI<FKGANX  (NKFI*NKFJ)  I 
ENO  I 

IF  NKFI  -.=  0 ...  X UPDATF  // 

THEN  BEGIN  ...  UPDATE  COl  1 FOP  Y UPDATE  // 

NKFPMAI X ( 0)  s NKFPMATX(0)-NKFPMATX(1)*NKFKGANX 
(1*0)  » 

FOR  NKFJ  = 2 STEP  1 WHILE  NKFJ  <3  NKFSTANO 
00  BEGIN 

NKFPMATX (NKFJ)  = NKFPMATX (NKFJ) -NKFKGANX 
(1*NKFJ)<*NKFPMATX(1)  I 
END  I 

NKFPMATX(l)  s NKFKGANX ( 1.0) *NKFRMATX  I 
END  I 

ENO  » 

END  I 
End  fini 
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■EyMin—  L-mniiiiiwiww*  i..  ,,  , 


c.pnhit  aed 


I 


begin 

.INSERT  CPNOWN  I 
.INSERT  CNODATA  I 
.INSERT  NRBMAST  5 
.INSERT  NRRAUX  | 

• INSERT  NRBGNAV  I 


.INSERT  CPNCONSf  I 


integer  procedure  c. 

PNPACK  I 

...  (FIRST  BYTE.  NO.  BYTES) 

e 3z  packed  // 

procedure  C.PFXhCD  i 

• • • 

(FIXEDPTVARBL*  NO.  BYTES)  // 

DEFINE  procfdure  c.pnhit  TOME 

...  DEFINE  the 

SWITCH  NUMBER  BRANCH  // 

regin 

SWITCH  CPNHRNCH 

t M , 

define  THE  SWITCH  NUMBER  BRANCH 

HITCOUNT. 

• • • 

0 // 

slu. 

• • • 

1 // 

SLUf 

• • • 

2 // 

SlU* 

• • • 

3 // 

slu» 

• • • 

4 // 

slu. 

• • • 

5 // 

HITCOUnT* 

• • « 

h //  % 

FI.YTO, 

• • • 

7 // 

ALTSELCT. 

• • • 

fl  // 

dspselct. 

• • • 

9 // 

STR.wODE, 

• • • 

10  // 

fastfwd. 

• • • 

11  // 

FORWARD. 

C • • 

12  // 

rfversf. 

• • • 

13  // 

fastrfv, 

• • • 

14  // 

HITCOUNTt 

• • • 

15  // 

ACCEPT, 

• • • 

16  // 

REJECT, 

• • • 

17  // 

altelev. 

• • • 

18  // 

automan, 

• • • 

19  // 

Landsfa, 

• • • 

20  // 

INS1SEI  , 

• • « 

21  // 

INSIDIT. 

• • • 

22  // 

INS2SFL, 

t • • 

23  // 

INS2DIT, 

• • 

24  // 

oeadslct  » 

• • • 

25  // 

ADDPOR, 

• • # 

26  // 

HITCOUNT, 

• • • 

27  // 

HITCOUNT* 

• • • 

2H  // 

INS1ENRI  , 

• * • 

29  // 

INS2ENHI., 

• » I 

30  // 

kitcount  1 

• • • 

31  // 

...  DEFINE 

ALT/ELEV  ALT  CAL  MODE  BPANCH  // 

SWITCH  CPNAEBN 

r 

acmoands* 

• • • 

0 // 

ACM1AN02* 

• • • 

1 // 

AC*1AND2* 

• • • 

2 // 

ACM3, 

• • • 

3 // 

ACM4, 

• • • 

4 // 

ki.hvariij'S  ♦ 

• • • 

5 // 

ARE  THERE  NO  MORE  HITS  // 


325 


C.PNHlT  Af.i> 


ANYHITS  ■ ' * 

V « 


PLVTn  j 

ALTSELCT  1 

SLU  i 
OSPSELCT  I 

STRKOOE  S 

FASTFWO  : 

FORWaRO  : 
REVERSE  ! 


CPNM]T<0)  «»  0 
, GOTO  RETURN 

*,£  8FGTN  ...  OBTAIN  THE  NEXT  HIT  // 

CPMTJ1  « CPNHlT<CPNHIT{On  I 
^PNRWCH  ■ PNTM  1 

...  is  thf  new  status  off  // 

IF  rPNTIl  u 

...  IS  THE  HI'  A POSITION  SWITCH  // 

Then  if  cpnt  < ~<!S 

OR  (CPNTI1  > = -U  AND  CPNT  1 1 <=  -11) 

OR  CP';’’'.  >=  -S 
"hEN  r‘,Nfil  * -CPNT  1 1 
ELSE  ...  IF  NOT.  I6N0RE  // 

GOTO  HITCOUmT  I 

...  NOW  BRANCH  ON  THE  SWITCH  NUMBER  // 

Goto  CPNHHNCH(CPNTII)  » 

...  IF  THE  fly  to  REQUEST  IS  AN  OAP...  // 
jsr  iXTYPE (CPSXPTR)  = = 6 

THF'  GOTO  HITCOUNT  ...  IGNORE  THE  REQUEST  // 

Ei$-  H-.Glf/'  ...  TURN  ON  the  fly  to  light  // 

CPNOUT 1 3 = CPNOUT 1 3 .V.  KMASK1R  l 
CPNFLYTO  = 1 J ...  SET  FLYTO  FLAG  // 

GOTO  ZEROCLOK  I 
EMU  I 

...  REVERSE  hsl  and  hr  light  status  // 

CPNOUT  1 3 = CPnOUT  1 3 .X,  "00006000''  J 

CPNHSl  = CPNOUT 13  .A.  "00006000"  ) ...  SET  HSL/HR  FLAG  // 
GOTO  ZEROCLOK  ; 

...  SET  RESET  INDICATED  SLU  STATUS  // 
CPNSLU(CPNTIl)  = CPNSWCH  » 

GOTO  HITCOUNT  I 

...  CYCLE  THE  LIGHT  TEMPLATE  // 

CPNOIS  = CPNDTS  ,LS.  1 I 
IF  CPNOIS  .A.  KMASK15  -.=  0 

THEN  CPNOIS  = KmASKIV  J 

IF  CPNOIS  .A.  KMASK17  0 ...  IS  THE  NEW  MODE  NV  // 

them  cpnoclok  * o ...  stop  the  rlink  timer  // 

ELSF  ...  RE-STAPT  The  BLINK  TIMER  // 

CPMDCLOK  * 1 » 

CPnoUTIA  * (CPNOUT 14  .A.  "FFFFOFFF")  .V.  CPNOIS  I 

...  light  appropriate  sfgment  ano  set  the 

MODE  FLAG  // 

CPNDSLP  = CPNniS  .RS.  13  l 
GOTO  ZEROCLOK  ( 

...  REVERSF  STFEH  MODE  LIGHTS  ANO  FLAG  // 
CPN0>‘ . 1 3 = CPNOUT 13  .X.  "OOOOOCOO"  ( 

CPNSl :»H  = (CPNOUT13  "OOOOOCOO")  ,RS.  11  I 

GOTO  ZEROCLOK  » 

...  SET  FWD  /.REV  REQUEST  FLAG  // 

CPNFWDRV  = 10  « 

GOTO  FhORVOFF  J 
CPnFWORV  = 1 » 

GOTO  FWORVOFF  ( 

CPNFWORV  ' -1  J 


'w-  > wm1 


C.PNHIT 

FASTrEV 

FWDRVOFF 

ACCEPT 


PEJECT 


ALTELEV 

ACM1AND2 

ACMA  : 


ACM  J I 


AEO 


I CPNFWDRV  * -10  t 

I ...  IF  THE  NEW  STATUS  IS  OFF,  OP  IF  THE 

XHAIH  MODE  IS  ID...  // 

IF  CPNSWCH  < 0 OR  CPSIO  -=  0 

then  cpnfwqrv  * o » ...  remove  fwd  / rev  request  flag  // 

GOTO  ZEHOCLOK  | 

...  IGNORE  UNLESS  ALTITUOE  CALIBRATION 
MODE  IS  4 // 

IF  CPNACM  aa  4 
Them  BEGIN 

...  SET  ALT  CAL  COMPUTE  FLAG. AND  PREPARE 
TO  RECEIVE  KALMAN  VERDICTS  // 

CPNACC  = CPNACS  I 
CPNACM  a 5 » 

NKFAHJTM  = 0 » 

NKFAHJTA  a 0 I 
END  » 

GOTO  HITCOUNT  t 

...  IGNORE  IF  ALT  CAL  MODE  IS  5.  OTHERWISE 
ENU  ALT  CAL  // 

IF  CPNACM  is  5 
THFm  GOTO  HITCOUNT 
else  BEGIN 

CPN0UT14  a CPNOUT 14  .A.  "FFFRFFFF"  I 
CPN0UT9  s CPN0UT9  .V.  "OOFFFFFF"  I 
CPNACM  * 0 I 
CPNHAC  * 0 J 


EMO  ? 

GOTO  HITCOUNT  I 

t ...  BRANCH  ON  alt  CAt  MODE  // 

GOTO  CPNAEBN (CPNACM)  » 

i ...  TURN  OUT  ELEV  LIGHT.  PULL  HIGH  ALT  CAL 

FLAG  DOWN  // 

CPN0UT14  a CPN0UTI4  .A.  KRMASK11  » 

CPnhAC  * 0 I 
CPNACM  a 3 | 

IF  NCRALTOK  =s  0 ...  ARE  THE  RADAR  ALTIMETERS  DOWN  // 

...  IS  THE  FLR  UNAVAILABLE  // 

then  if  cpflRon  ==  o 

then  begin  ...  terminate  alt  cal  // 

CPN0UT9  a CPN0UT9  .V.  "OOFFFFFF"  I 
CPNOUT 14  a CPNOUT1 A , a „ KRMASK 1 4 » 

CPNACM  a 0 I 
END 

ELSt  HtGlN  ...  SET  HIGH  ALT  CAL  FLAG  AND  ZERO 
THE  DELTA  bufffr  // 

CPNHAC  = 1 » 
cpnoelta  = 0 » 

END  ( 

GOTO  HITCOUNT  » 

...  RECORD  WHICH  NAV  SYSTEM  WAS  USED  FOR 
ALT  CAL  // 

CPNACS  a CPNNmS  » 

CPNOUT 1 A a CPNOUT 1 A .V.  KMASK14  t ...  AOVANCE  TO  MODE  4 // 
CPNACM  a * | 


i 

i 

! 

\ 

1 
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■ 


C.PNHIT  aeo 


ACM0ANU5  : 
aUTOmAN  | 


LANOSEA  t 
INS1SEL  I 
TNS10IT  t 


TNS2SEL  t 
INS20I'T  j 


OEADSLCT  : 
aODRDR  '• 
TNSlENrtL  : 

INS2ENHL  : 

• • • 

7EROCLOK  : 


end 

ENO  FINI 


GOTO  MITCOUNT  I 

...  reverse  lights  and  node,  initialize 

SYSTEM  REUUEST  // 

CPNOUTl*  a CPN0UT14  .X.  "OCOOOOOO"  I 
CPNMANH  * (CPN0UT14  .A.  "OCOOOOOO")  .RS.  27  I 
CPMMHSa  a NCPRNV  t 
GOTO  HITCOUNT  I 

...  REVERSE  LAND  / SEA  MODE  // 

CPNI.ANOB  = GPNLANDU  .X.  "(S0000000"  I 
GOTO  HITCOUNT  I 

...  REQUEST  INSl  // 

CPnnMS  = 4 I 
GOTO  HITCOUNT  I 

...  IF  IN  MANUAL  MODE*  CYCLE  LIGHT  AND 

TENTATIVE  REQUEST. RESET  DISPLAY  CLOCK 
TO  ALLOW  ONE  SECOND  MOOE  SET  DELAY  // 

IF  OPNMAN  xa  o 

Them  hfgin 

CPNMDIT  = CPNMDIT  ,1.S.  1 I 
IF  CPNMDIT  .A.  KMaSK?7  is  0 
Then  CPNMOIT  = KMASK31  » 

CPN0UT4  r CPM0UT4  .A.  "FFFFFRFF" 

.V.  (CPNMDIT  .LS.  8)  I 
CPNCLOCK  : 13  I 
END  I 

GOTO  HITCOUNT  I 
CPmmMS  a 2 I 
GOTO  HITCOUNT  i 
IF  CPNMAN  xx  n 
THEN  HEGIN 

CPNAOIT  x CPN40IT  .LS.  1 » 

IF  CPNAOIT  .A.  KMASK27  -=  0 
then  cpnadit  = kmask31  » 

CPNOUTO  = CPNOUTO  .A,  "FhFFFFFF" 

.V.  (CPNADIT  .LS.  24)  ; 

C-PNCLOCK  r 13  I 
F NO  \ 

GOTO  HITCOUNT  | 

...  SET  REQUEST  FLAG  TO  DEAD  RECKON  // 

CPmnMS  a 1 I 
GOTO  HITCOUNT  I 

...  REVERSE  DR  / ADDR  REQUEST  FLAG  // 
CPnODSH  = CPNQUS8  .X,  "U0000003"  I 
GOTO  HITCOUNT  I 

...  SET  INS  ENABLE  FLAG  TO  APPROPRIATE 

VALUE  //  , 

CPniNSI  = CPNSWCH  I 

GOTO  HITCOUNT  5 $ 

CPNTNS?  = CPNSWCH  I 
GOTO  HITCOUNT  I 

ALL  RRAHCHES  RFTURN  HERE  // 

...  SET  THE  DISPLAY  CLOCK  TO  ZERO  // 

CPNCLOCK  a 0 I 

pn^iiiT  T i a t — i o i j • 

a » a v • vnn  i m u / i » 

GOTO  ANYHITS  I 

end  » 

l ...  OF  HIT  PROCEDURE  DEFINITION  // 
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ij:  ft?* ummmm. 

8 


i 


CPNOWN  AED 


TNTFGER  CPNMTIME  » 

integer  cpntimb  I 

INTEGER  rPNCLOCK  » 
INTEGER  CPNCLOKH  » 
INTEGER  CPNHSL  » 
intfger  cpnoclok  t 
INTFGER  CPNOIS  » 

intfger  cpnacm  » 

INTEGER  CPNmqiT  I 
integer  cpnaott  X 

INTEGER  CPNTI1  I 
INTEGER  CPNTB1  » 
real  CPNTFl  I 
INTEGER  CPNTI2  I 
TNTEGFR  CPNTP2  I 
REAL  CPMTF2  I 

INTEGER  CPNSWCH  5 
INTEGER  cpnacs  I 

INTEGER  CPNPPOOK  I 
INTEGER  CPNSELNO  ; 
INTEGER  CPNiJPRJ  I 
INTEGER  CPNMAGI  I 

integer  cpnsltyp  I 

REAL  CPNTNEt.V  » 

REAL  CPNSELON  * 

REAL  CPNSELAT  l 
REAL  CPNSLELV  I 
INTEGER  CPNSTRNO  I 
INTEGER  CPNMAG2  « 
integfr  cpnsttyp  ; 

REAL  ARRAY  CPNSLPOS ( 1 ) 
real  ARRAY  CRNTAR(I)  I 
INTEGER  ARRAY  CPNMCODE 


MISSION  TIME  IN  MAJOR  FRAMES  // 

HIT  NAME  FOR  MISSION  TIME  // 

OISPLAY  CLOCK — A MOD  10  COUNTER  // 

BIT  NAME  FOR  THE  OISPLAY  CLOCK  // 

hr/hsl  flag  // 

DISPLAY  SELECT  blink  TIMER  // 

OISPLAY  SCLECT  TEMPLATE  // 

ALT  CAL  MODE  // 

INS1  dit  reouest  flag  // 

INS2  DIT  REOUEST  FLAG  // 

TEMPI  // 

TEMPI  // 

TEMPI  // 

TEMP2  // 

TEMP2  // 

TEMP2  // 

VARIABLES  LOCAL  TO  C.PNHIT  // 

ACTIVE  HIT  SWITCH  NO.  / STATUS  // 

NAV  SYSTEM  USED  FOR  Al.T  CAL  // 

DATA  LOCAL  TO  C.PNDISP  // 

PRESFNT  POSITION  DATA  OK  FLAG  // 

SELECTED  PT.  SEU  NO.  // 

UPDATE  REJECT  LIGHT  TEMPLATE  // 

SELECTED  POINT  MAGWHEEL  TIMER  // 

SELECTED  POINT  TYPE  // 

TERRAIN  ELEV,  .FEFl  // 

SELECTED  POINT  LONG  .RADIANS  // 

SELECTED  POINT  LAT  .RADIANS  // 

SELECTED  POINT  ELEV. FEET  // 

steer  POINT  SEQ  NO.  // 

STEKR  POINT  MAGWHEEL  TIMER  // 

STEER  POINT  TYPE  // 

X ...  SELECTFO  POINT  POSITION  // 

...  TIME  AND  RANGE  TO  SELECTEO  PT  // 
o)  X ...  MAGWHEEL  DRIVER  CODE  // 

THE  FOLLOWING  ARE  B 32  NAMES  FOR  THE  ABOVE 
OUTPUTS  TO  THE  PANEL  // 


INTEGER 

integer 

INTEGER 

INTEGER 

INIEGFR 

INTEGFR 

INTEGER 

INTEGER 

integer 
integer 
integfr 
INTEGFR 
INTEGER 
T M Tr  J5CO 

INTEGER 

integer 


CPNOUTO 
CPNOUTl 
CPN0UT2 
CPN0UT3 
TPN0UT4 
CPN0UT5 
CPN0UT6 
CPN0UT7 
CPN0UT3 
CPN0UT9 
CPMOUTIO  X 
rPNOlJTll  1 
CPN0UT12  » 

PUWOl  IT  1 1 t 

V*  * • 4 */  * 

CPNOUTl 4 » 
CPN0UT15  I 


// 

THE  FOLLOWING  IS  AN  array  NAME  FOR  THE 
OUTPUT  TO  THE  PANELS  // 


2 
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Iffi&xafd 


cpnown  aeo 


INTEGER  ARRAY  CPMOUlAdS)  I 

...  THE  following  variables  awe  REFERENCED  by  othfr  programs  // 


INTEGER  CPNSTFER  I ... 
I NTe  OER  cpnstpb  * 

integer  CPNFwnRV  » ... 

INTEOFH  CPNROLL  1 

jntf.rfp  cpnacg  » ... 

integer  cpnhac  * .... 

INTEGER  CPNMAM  I 
INTEGER  CPNMANB  I 

INTEGER  CPNLAMD  » 

INTEGER  CPNLANOB  I ... 
INTEGER  CPNNMS  I 
INTEGER  CPNNMSB  « ..-. 

INTEGER  CPNOOG  » 
integer  cRNnnsH  ; ... 

INTEGER  CPNINSl  » 

INTEGER  CPNIMS2  I 

INTEGER  CPNSlUA  I 

INTEGER  CPNSLUL  t 

INTEGER  rPNSllJR  I ... 

INTEGER  CPNSUJI  I 

INTFGFR  CPNSHIF  I 

peal  cpndf.lt a ; 

INTEGER  array  CPMSLUISI 


INTEGER  CPNFLYTO  I , 
INTEGER  cpndsi.  * 
INTEGER  CPNDSI  H I 

CPNSTPB  CPNSTEER1 

CPNmanh  * = $ CpNM AN  » 
CPNlANDH  t = * CPNeAND 


CPNN'iSH 

cpnddsh 

CPNSl.HA 

CPNSLUL 

CPNSLIIR 

CPNSUJI 


* = V CPNN-b  I 
iai  CPNDOS  I 
«;  = $ r.PNSi.UU) 
CPNSLUI2) 

*=*  cpnsi.uo) 
*=*  cpnsluuj 


CPNSl  UK  $ = % CpNSl.U  (S) 
CPNTIMH  * = * CPNMTIME  I 
CPNCLOKH  Jan  rPNCLOCK 
CPNTR 1 tst  CPMTF1 
CPNTH?  * = $ CPnTF?  J = * 
CPNOSlB  S=S  CPNDSL  I 


STEER  MODE  0 — THK  1—  DIR  // 

HIT  NAME  FOR  STEER  MODE  // 

FORWARD  REVERSE  REQUEST  // 

FORWARD  REVERSE  COMMAND  // 

ALT  CAL  COMPUTE  // 

HIGH  ALT  CAL  REQUEST  // 

AUTO/MAN  mode  flag  // 

HIT  NAME  FOR  AUTO/MAN  FLAG  // 
LAND/SkA  FLAG  // 

BIT  NAME  rOR  LAND/SEA  FLAG  // 

NAV  SYSTEM  SELECT  // 

HIT  NAME  FOR  NMS  // 

DR/AODR  REQUEST  // 

BIT  NAME  FOR  OR/AOOR  // 

I NS  1 ENABlE/OISABlE  // 

INS2  ENAHLE/OISABlE  // 

aft  // 

left  pylon  // 

RIGHT  PYLON  SLU  enable  // 

INTRMO  // 

FORWARO  // 

ALT  CAL  DELTA  BUFFER  // 

» ...  THIS  IS  The  Slu  status  table. 
IT  IS  »0VERLAYE0*  *ITh  the  SLU 
STATUb  WORDS  ABOVE  // 

fly  to  flag  // 
oispaly  select  flag  // 

HIT  NAME  FOR  CPNOS2  // 

OVERLAY  DECLARATIONS  FOP  CPNOWN  // 


CPNTI1 

CPMTI2 


330 


»^>rWMW:^«  MMM  »»M  !■*■  rnmmm,  ■■■■»...  . ■ «— 


cnooata  aed 


INTEGER  ARRAY  CPNHIT<7) 
INTEGER  CPSin  » ... 

INTEGER  CPPLPON  » ... 

INTEGER  CMALTCAL  I ... 
INTEGER  CPKALTCL  » ... 

REAL  cpktnelv  » ... 

INTEGER  CPSNUIP  » *.. 

INTEGER  CMCSTP  I ... 
INTEGER  CMCSPIO  I ... 
INTEGER  CMCSPSN  I ... 
INTEGER  CAFEDTF  * ... 

INTEGER  CAFSMOOE  I ... 
INTEGER  ARRAY  CPRCIM7)  t 
INTEGER  ARRAY  CMXtAT<7> 
INTEGER  ARRAY  CMXLONGI7) 
INTEGER  ARRAY  CMXELEV l 7) 
INTEGER  ARRAY  CMXQUAL  ( 7 ) 
INTEGER  ARRAY  CMXSQN0(7) 
INTEGER  ARRAY  CMXTYPE ( 7 ) 

INTEGER  cpsxptr  I 
INTEGER  NCRALTOK  I ... 
REAL  NCRALT  | ... 

BEAL  NCALTP  I ... 

REAL  NSTTG  J ... 

REAL  NSPNG  I ... 

REAL  NLAT  I ... 

REAL  NLONG  t ... 

REAL  NVGND  I ... 

heal  nhgt  I ... 

REAL  nthead  I ... 

REAL  nwheao  \ ... 

real  nwtnd  » ... 

PEAL  NHniSP  J ... 

INTEGER  NORMonE  I ... 
INTEGER  nCOOPCUT  I ... 
INTEGER  NCAALCPT  I ... 
INTEGER  NCMALGPT  » ... 

INTEGER  NVFSTRT  I ... 

integer  nkEarjtm  ; ... 

INTEGFR  NKFARjTA  I ... 
INTEGER  NCAVAILN  I ... 


INTEGER  ncavaila  ? ... 

INTEGER  NCMOIT  I 

INTEGER  ncadit  I 

INTEGER  ncprnv  I ... 


» ...  the  nav  program  hit  table  // 
10  MODE  FLAG  // 

FORWARD  LOOKING  RADAR  ON  /( 

next  oest.  an  act  cal  // 

IKB  ALT  CAL  REGUEST  // 

1KB  TERRAIN  ELEVATION  // 

POSITION  UPDATE  IN  PROGRESS  // 
STEER  POINT  FLAG  // 

STEER  POINT  TYPE  // 

STEER  PT.  SEO.  NO.  // 

FLT  DR  ENGD  / AUTO  TF  FLAG  // 
FLIGHT  DIRECTOR  MODE  // 

...  BCD  ARRAY  // 

< 

I 

I 

I 

« 

f 

POINTER  INTO  CMXHAIR  // 

RADAR  ALTITUDE  OK  // 

RADAR  ALTITUDEiFEET  // 

PRIME  ALTITUDE.FT  . // 

TIME  TO  DESTINATION. SEC  // 

RANGE  TO  DESTINATION  // 

DISPLAY  LAT. RADIANS  // 

DISPLAY  LONG.  KACIANS  // 

DISPLAY  GND  SPEED. FT  / SEC  // 
GROUND  TRACK. RADIANS  // 

TRUE  HEADING. RADIANS  // 

WIND  HEADING. RADIANS  // 

WINO  SPEED.  FT  / SEC  // 

HEIGHT  AROVF  sea  level. FT  // 

OEAD  RECKON  MODE  // 

OOPPLER  CUT-OUT  FLAG  // 

INS2  UP  // 

IN01  UP  // 

DEAD  RECKON  RESTART  FLAG  // 

I NS  1 alt  CAL  REJECT  FLAG  // 

INS?  ALT  CAL  REJECT  FLAG  // 

INS1  OIT  AVAILABLE  FLAG  // 

INS?  OIT  AVAILABLE  FLAG  // 


PRIME  SYSTEM  FLAW  // 


r 

j 

i 
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REAL  NILATM  I ... 
REAL  NTLONM  I ... 
Real  nialtm  » ... 
REAL  NIVNM  » ... 
REAL  NTVEM  I ... 
REAL  nihdotm  » ... 
REAL  NIPSITM  • I ... 
REAL  NIPSIMM  I ... 
REAL  NIPRAVM  » ... 
HEAL  NCMPITCH  I ... 
REAL  NCMROLL  » ... 
REAL  NCMYAW  I ... 
REAL  NOPOOT  » ... 
REAL  NCMRDOT  I ... 
REAL  NCMYOOT  I ... 

navigation  data  Common 


Real  nialeam 
real  N7V-XM 
REAL  NIVYM 
REAL  NIVZm 
REAL  NCMAX 
REAL  NCMAY 
RFAL  NCMA2 
REAL  NTOVAAM 
Real  ntovaym 

REAL  NIOVAZM 
REAL  NIC12M 
RFAL  NIC22M 
REAL  NTC32m 
REAL  NTC13M 
REAL  NTC23M 
RFAL  NIC33M 
REAL  MC120M 
RFAL  NT0220M 
HEAL  NTC320M 
REAL  NIC130M 
RFAL  NTC230M 
REAL  NIC330M 
REAL  NIOMEGXM 
REAL  NIOMEGYM 
RFAL  NTOMEGZM 
REAL  NIPHOXM 
REAL  NTRHCYM 
REAL  NTPRXm 
REAL  NIPRYM 
REAL  NIAXCM 
REAL  NIAYCm 
REAL  NIAZCM 
RFAL  NIOAXCM 
RFAL  NIOAYCM 
REAL  NIOAZCM 


LAT I TL'fiE  (RADIANS)  // 

LONGITUDE  (RAO IANS)  // 
ALTITUOE(EEET)  // 

VELOCITY  NORTH (FT/SEC)  // 

VELOCITY  EAST (FT/SEC)  // 

ALTITUDE  RATE(FT/SEC)  // 

TRUE  HEADING(RADIANS)  // 

MAGNETIC  HEAOING(RAOIANS)  // 

LOCAL  GRAVITY  (FT/SEC*<,2)  // 
PITCH(RADIANS*  // 

ROLL(RAOIANS)  // 

YAW (RADIANS)  // 

PITCH  RATECRAD/SEC)  // 

ROLL  R A f E (RAD/SEC)  // 

YAW  RATE (RAO/SEC)  // 

// 

TO  MASTER  AND  AUXILIARY  // 

// 

WANDER  ANGLE (RADIANS)  // 

X PLATFORM  VELOCITY (ET/SEC)  // 

Y PLATFORM  VELOCITYIFT/SEC)  // 

Z PLAIEORM  VELOClTY(ET/SFC)  // 

X ACCELEROMETER (ET/SEC/ERAME)  // 

Y ACCELEROMETER (FT/SEC/FPAME)  // 

1 ACCELEROMETER (FT/SEC/ERAME>  // 
DELTA  X VELOCITY ( F T/StC/ERAME ) // 
DELTA  Y VEL0CITY(ET/SEC/ERAME>  // 
DELTA  Z VELOCITY (FT/SEC/FRAME)  // 
DIRECTION  COSINE  C(l. 2)  // 
DIRECTION  COSINE  C(2.2>  // 
DIRECTION  COSINE  C(3»2)  // 
DIRECTION  COSINE  C ( 1 • 3 > // 
DIRECTION  COSINE  C(2»3)  // 
DIRECTION  COSINE  C(3.3)  // 
DERIVATIVE  OF  C ( 1 * 2 ) // 

DERIVATIVE  OF  C(E»2)  // 

DERIVATIVE  OF  C ( 3 *2)  // 

DERIVATIVE  OF  C ( 1 *3)  // 

DERIVATIVE  OF  C(?« 3)  // 

DERIVATIVE  OF  C(3t3)  // 

EARTH  RATE  ABOUT  X (PaD/SEC)  // 

EARTH  RATE  ABOUT  Y(PaD/SFC.)  // 

EAHTH  PATE  ABOUT  Z(RAD/SEC)  // 

CRAFT  RATE  AROUT  X(RaD/SEC)  // 

CRAFT  PATE  ABOUT  Y'RAD/SEC)  // 

PLATFORM  RATE  AROUT  X(RAD/SEC>  // 
PLATFORM  RATE  ABOUT  Y (RAD/SEC ) // 
CORRECTED  X ACCEL (F  T/SEC/ERaM)  // 
CORRECTED  Y ACCEL (F I/SEC/EP AM)  // 
CORRECTED  Z ACCEL (FT/SEC/ERAM)  // 
X ACCEL  NOISE  EST (FT/SEC/ERAM)  // 

Y ACCEl  NOISF  FST (FT/SFC/FRam)  // 
Z ACCEL  BIAS  EST9ET/SEC/FRAME)  // 

// 
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REAL  NKFPRJTM  t 

REAL  ARRAY  N6IhSM(  SO) 

RFAL  N*P010lK  I ... 

REAL  NKP0201N  I ... 

REAL  ARRAY  NKEPMATM(1R9)  I 
REAL  ARRAY  NKXHATm(IB)  t 
REAL  ARRAY  NKVkSVM(A)  I 


if 

POSITION  FIX  REJECT  FLAG  // 

COVARIANCE  ELEMENT  P(l,D  ft 
COVARIANCE  ELEMENT  P«2.l)  // 
INS  1 COVARIANCE  MATRIX  // 
...  INS  1 STATE  VECTOR  // 

...  INS  I MEASUREMENT  VECTOR  ft 
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NILATa 

N ILONA 

NTALTA 

NIVNA 

NIVEA 

NIHOOTA 

NIPSITA 

NIPSIMA 

NIGRAVA 

NCAPITCH 

NCAROLL 

ncayaw 

NCAPDOT 

NCAROOT 

ncaydot 


LATITUDE(RAOIANS)  // 
LONGITUDE(RAUIANS)  // 
ALTITUDE (FEET)  // 

VELOCITY  NORTHJFT/SEC)  // 
VELOCITY  EAST (FT/SEC)  // 

ALT ITUOE  RATE (FT/SEC)  // 

TRUE  HEAOING(RAOIANS)  // 
MAGNETIC  HEADING(RADIAMS)  // 
LOCAL  GRAVITY(FT/SEC*»  ) // 
PITCH(RAOIANS)  // 

. HULL (RADIANS?  // 
YAMHA0IAN5)  // 

PITCH  HATE(RAD/SEC)  // 

ROLL  RATE (RAO/SEC)  // 

YA*  HATE (RAO/SEC)  // 


NAVIGATION  DATA  COMMON  TO  MASTER  AND  AUXILIARY 


nialfaa 

NIVXA 

NIVYA 

NIVZA 

NCAAX 

ncaay 

NCAAZ 

NTDVAXA 

NIOVAYA 

NTDVAZA 

N ’Cl  2a 

NIC22A 

NTC32A 

NTC13A 

NTC23A 

NTC33A 

NIC120A 

NIC220A 

NIC32DA 

NIC13DA 

NTC23DA 

NIC330A 

NTOMEGXA 

niomegya 

niomf.gza 

NIRHOXA 

NIRHOYA 

NJPRXa 

ntprya 

niaxca 

ntayca 

NT  AZCA 

NTDAXCA 

NTOAYCA 

ntdazca 


WANDER  ANGLE(RADIANS)  // 

X PLATFORM  V£LOCITY(FT/SEC)  // 

Y PLATFORM  VELOCITY (FT/SEC)  // 

2 PLATFORM  VELOCITY (FT/SEC)  // 

X ACCELEROMETER(FT/StC/FRAME)  // 

Y ACCELEROMETER(FT/SEC/FRAME>  // 

7.  ACCELEROMETER(FT/SFC/FRAME>  // 
DELTA  X VELOCITY (F T/3EC/FRAME > // 
DELTA  Y VELOCITY (FT/SEC/FRAME)  // 
DELIA  Z VELOCITY(FT/SEC/FRAME>  // 
DIRECTION  COSINE  C(1.2)  // 
DIRECTION  COSINE  C<2.2>  // 
DIRECTION  COSINE  C<3.2)  // 
DIRECTION  COSINE  C(l»3>  // 
DIRECTION  COSINE  C(2t3S  // 
DIRECTION  COSINE  C(3*3>  // 
DERIVATIVE  OF  CC1.2)  // 

DERIVATIVE  OF  C (2*2)  // 

DERIVATIVE  OF  C (3i2>  // 

DERIVATIVE  OF  C(l*3>  // 

DERIVATIVF  of  C (2«3)  // 

DERIVATIVE  OF  C ( 3 1 3 ) // 

EARTH  RATE  AROUT  XtRAD/SEC)  // 
EARTH  RATE  AROUT  Y{HAD/SEC)  // 
EARTH  RATE  AROUT  7 (RAD/SEC)  // 
CRAFT  RATE  ABOUT  X (RAD/SFC)  // 
CRAFT  RATE  AROUT  Y(«AD/SFC)  // 
PLATFORM  RATE  aBOUT  X (RAD/SEC)  // 
PLATFORM  HATE  ABOUT  Y (RAD/SEC)  // 
CORRECTED  X ACCtL < FT/SFC/FRAME ) // 
CORRECTED  Y ACCF.L 'FT/SEC/FRAME)  // 
CORRECTED  Z ACCEL (FT/SFC/FRAME)  // 
X ACCEL  NOISE  EST (FT/SEC/FRAME)  // 

Y ACCEL  NOISE  EST(FT/SFC/FRAME)  // 
Z ACCEL  RIAS  EST (FT/SLC/FRAME)  // 


7 (RAD/SEC) 
X (RAD/SFC) 
Y (RAD/SFC ) 


KALMAN  FILTER  OATA 


334 


“ .t-5.  • * •JW«%Si4;>  ^ 


L 


nrbaux  aeo 


// 


HEAL  NKFPRJTA 


« 


POSITION  FIX  REJECT  FLAG  // 


REAL  ARRAY  NAINSA ( 50)  ) 


REAL  NKP0101A 
REAL  NKP0201 A 
REAL  ARRAY  nkFPMATA < 189)  » 

real  array  nkxhataug)  t 
REAL  ARRAY  NKYHSVA(A)  I 


COVARIANCE  ELEMENT  P(l*l)  // 
COVARIANCE  ELEMENT  P(2cl>  // 

. covariance  matrix  array  // 
. STATE  VECTOR  // 

. MEASUREMENT  VECTOR  // 
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«FA|  Nhr»M**l  | 

MFAI  NftHKlM  t 
MMt  NkFIMP'1  I 

intfoeh  nhfmo«m  • 

NCOPOVL  I 


iNTFOrW 

iNrrnrn 

tNTrnn* 

iNfrorif 

INfEor.H 

iNTFfjER 


NKF!  I 
NKr.l  » 

NKFH  • 

NHM»  I 
NKFT  I 
REAL  NKFKGO  5 
INTEGER  NKFSTANO  I 


REAL  NKFRMaTX  I 
REAL  NKFAN  I 


m 


& 


i 


6. 


E 


i 

i 

i 

! 


real  nkfae  ♦ 

REAL  NKFEX  » 

REAL  Rtf FEY  » 

INTEGER  NCPRIME  I 
REAL  CSNRON  I 
REAL  CSNPOE  » 

REAL  NCLATp  t 
REAL  NCLONP  | 

real  nlatc  I 
real  nlonc  I 

INTEGER  CMFPOUAL  I 
REAL  NRALT  f 

HEAL  ARRAY  NKFKC.AlN  (38)  I 
INTEGER  ARRAY  NkFC0LMN(18) 
REAL  ARRAY  KRPMATX (2)  I 

real  array  nkinitp ( 18)  ; 
real  kntne  t 
real  KERADltJS  I 
reau  kdflta  r i 
REAL  kgravo  » 

REAL  KGRAV1  I 
real  KGRAV?  I 
real  KELPTCTY  I 
REAL  K2FORE  I 
REAL  KIORE  « 
real  KEARTHR  I 
REAL  KNK 1 I 
REAL  KNK2  » 

real  kone  I 


. I f Ml'ltll  am  ) *1 1 (III  Atlf  / / 

...  I r MF*I»M  iVl*  t h I illlAMF  'f 
...  IMtf'iiHAHr  htmiAMF  // 

...  MAVIltAIIlIN  I A III  I 1 1 A I A |NIUA  // 
...  IMIS  I I I ON  F I A f YPF  M Ati  // 

...  I MOP  INOFA  // 

...  IOOP  INOFA  ft 
...  IMOP  INOFA  // 

...  titJhWHlPl  // 

...  SUGSCHJRT  // 

...  DENOMINATE  OF  KALMAN  GAIN  // 
...  ELEMENTS  IN  STATE  VECTOR 
LESS  1 // 

...  POSITION  MEASUREMENT 
NOISE (FT**2)  // 

...  NORTH  COMPONENT  OF  POS 
ERROR (FT)  // 

...  EAST  COMPONENT  OF  POS 
FRROR(FT)  // 

...  X TERM  IN  POS  TEST  // 

...  Y TERM  IN  POS  TEST  // 

...  PRIME  DATA  FLAG  // 

...  NORTH  MEASURED  POS  ERROR  (FT)  // 
...  EAST  MEASURED  POS  FRROR(FT)  // 
...  PRIME  LATITUDF(RAOIAnS>  // 

...  PRIME  LONGITUDE (RADIANS)  // 

...  OVERFLY  CHECKPOINT 
LATITUDE(RAO)  // 

...  OVERFLY  CHECKPOINT 
LONGITUDE (RAO)  // 

...  CHECKPOINT  DUALITY  INOEX  // 

...  DEAD  RECKONING  ALTITUOE  // 

...  KALMAN  GAIN  MATRIX  // 

I ...  SYMMETRIC  MATRIX  POINTERS  // 

...  POSITION  NOISE (FT**2)  // 

...  INITIAL  VALUE  OF  COY  MATRIX  // 
...  poition  test  CONST  // 

...  EARTH  RADIUS  AT  EQUAToRtFT)  // 
...  FRAME  TIME(SEC)  // 

...  GRAV1TATIONAL  CONSTANT  // 

...  GRAVITATIONAL  CONSTANT  // 

...  GRAVITATIONAL  CL..5TANT  // 

...  EARTH  ellipticity  // 

...  ?*KELPTCTY/i\ERADIUS  // 

...  1/KERADIUS  // 

...  FARTH  RATE(RAD/SEC>  // 

...  inertial  constant  // 

...  inertial  constant  // 

...  one  // 
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SYNONYMS  57.2958  - CPNK)  >,  ...  DEGREES/ RAD  I AN  // 

SYNONYMS  ,5921  = CPNK2  I ...  KNOTS/ IKT/SFC)  // 


SYNONYMS 

"80000000" 

= 

KMASKO  » 

SYNONYMS 

"40000000" 

s 

KMASK’  ; 

SYNONYMS 

"20000000" 

s 

KMASK2  t 

SYNONYMS 

"10000000" 

= 

KMASK3  J 

SYNONYMS 

"08000000" 

* = 

KMASK*.  » 

SYNONYMS 

"04000000" 

3 

KMASK5  1 

synonyms 

"02000000" 

3 

KMASK6  » 

SYNONYMS 

"01000000" 

= 

KMASK7  » 

SYNONYMS 

"00000000" 

S 

KMASK8  ) 

SYNONYMS 

"00400000" 

s 

KMASK9  5 

SYNONYMS 

"00200000" 

= 

KMASK 1 0 i 

SYNONYMS 

"00100000" 

= 

KMASK11  J 

SYNONYMS 

"00080000" 

KMASK12  1 

SYNONYMS 

"0004C000" 

= 

KMASK 1 3 1 

SYNONYMS 

"00020000" 

= 

KMASK 14  t 

synonyms 

"00010000" 

s 

KMASK1S  1 

SYNONYMS 

"00008000" 

s 

KMASK 16  1 

SYNONYMS 

"00004000" 

= 

KMASK 1 7 1 

SYNONYMS 

"00002000" 

3 

KMASK 1 8 1 

SYNONYMS 

"0000 1000" 

= 

KMASK 1 9 1 

SYNONYMS 

"00000800" 

3 

KMASK20  1 

SYNONYMS 

"00000400" 

= 

KMASK21  1 

SYNONYMS 

"00000200" 

3 

KMASK22  » 

synonyms 

"000001 00" 

= 

KMASK23  I 

synonyms 

"OOOOOOMO" 

= 

KMASK24  ) 

SYNONYMS 

"00000040" 

= 

KMASK2S  t 

SYNONYMS 

"00000020" 

3 

KMASK26  t 

SYNONYMS 

"00000010" 

3 

KMASK27  1 

SYNONYMS 

"00000008" 

= 

KMASK28  * 

SYNONYMS 

"00000004" 

= 

KMASK29  1 

SYNONYMS 

"00000002" 

3 

KMASKJO  1 

SYNONYMS 

"00000001" 

3 

kmaSk  3 1 1 

SYNONYMS 

"7FFFFFFF" 

= 

KRMASKO  j 

SYNONYMS 

"BFFFFFFF" 

= 

krmaski  ; 

SYNONYMS 

»0FFFFFFc" 

3 

KRMASK2  { 

SYNONYMS 

"FFFFFFFF" 

= 

KHMASK3  1 

synonyms 

"F7FFFFFF" 

3 

KRMASK4  1 

SYNONYMS 

"FHFFFKFF" 

3 

KRMASK5  1 

SYNONVMS 

"FOFFFrFF" 

= 

KHMASK6  1 

SYNONYMS 

"FFFCFFFF" 

3 

KRMASK7  { 

synonyms 

"FF7FFF  FF" 

= 

KWmASKR  1 

SYNONYMS 

"FFRFFF  FF" 

= 

KRMASK9  1 

SYNONYMS 

"FFnFFFFF" 

= 

KHMASKlO 

SYNONYMS 

"FFFFFFi-  F" 

= 

KRMAGkII 

synonyms 

"FFF7FFFF" 

3 

*!<MASK 1 2 

synonyms 

"FFFRFFFF" 

= 

v UMASK 1 3 

synonyms 

"FFFOFFFF" 

= 

KRmASK 14 

SYNONYMS 

"FFFFFFFF" 

3 

KWMASK15 

SYNONYMS 

"FFFF7FFF" 

= 

kWmASK 1 6 

SYNONYMS 

"FFFFflFFF" 

- 

khmask 1 7 

SYNONYMS 

"FFFFOFFF" 

3 

KRmASK 1 8 

f VMOi^yur 

llCrrr>rCrCII 
• r r r u*  r r 

3 

1 Cl7  \ O 
*\n  # / 

synonyms 

•FFFFF7FF" 

= 

KRMASK20 
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1 l 

j (» 

i SYNONYMS 

"FFFFFBFF" 

a 

KRMASK21 

<• 

* 

synonyms 

“FFFFFDFF** 

a 

KRMASK22 

SYNONYMS 

"FfffFEFF" 

c 

KRMASK23 

synonyms 

"FFFFFF7F" 

a 

KRMASK2A 

synonyms 

"PFFFFFBF" 

a 

KRMASK25 

synonyms 

''FFFFFFOF1' 

s 

KRMASK26 

synonyms 

"FFffFFEF" 

a 

KRMASK27 

synonyms 

••FFFFFFF7" 

• a 

KRMASK28 

synonyms 

"FFFFFPFH” 

8 

KRMASK29 

synonyms 

"FFFFFFFD" 

a 

KRMASK30 

synonyms 

"FFFFFFFE" 

a 

KRMASK31 
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SAMPLE  RAW  STATIC  AND  DYNAMIC  DATA 


Meaning  of  Raw  Data  Matrix  Elements 


Each  of  the  25  features  counted  by  the  instrumented  compiler  was 
assigned  a unique  row  in  a 25  x 25  raw  data  output  matrix.  The  meaning  of 
each  column  in  the  row  depends  upon  the  form  of  data  being  gathered,  and 
includes  histogram  as  well  as  specific  language  forms  and  constructs.  The 
following  table  presents  the  mean)  .ig  of  each  row  and  column  in  the  data 
matrix.  (An  "X"  indicates  that  the  element  has  no  meaning. ) A further 
explanation  of  each  row  is  given  following  the  table.  Column  0 is  the  sum 
of  all  the  other  columns. 
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Table  18.  Format  of  Raw  Data  Output  From  Instrumented  Compiler 
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Row  Label 


ELSE 


FOR 


L-STEP 


R-STEP 


UNTIL 


FORMW 


HIST 


BOOL 


EQL, 
GEQ.  etc. 


Explanation 

Columns  represent  forms  of  statements  following  the 
THEN  in  IF-THEN  or  IF -THEN -ELSE  statements.  Onl/ 
columns  1 through  7 have  meaning. 

Same  as  for  IF,  above,  except  following  ELSE. 

Columns  represent  forms  of  FOR  statement 
(FOR-STEP-UNTIL,  FOR- WHILE,  etc.)  The  column 
labeled  "Mult"  represents  the  number  of  "FOR-lists". 
Only  columns  1 through  6 have  meaning. 

Columns  represent  the  form  of  FOR-loop  starting  value 
(FOR  var  = value).  Only  columns  0 through  4 are 
meaningful. 

Same  as  L-STEP,  except  for  the  FOR-loop  increment 
(FOR  var  = value  STEP  inc.) 

Same  as  L-STEP  and  R-STEP,  except  for  the  FOR-loop 
iteration  limit  (FOR  var  = value  STEP  inc  UNTIL  limit). 

Columns  represent  the  form  of  statement  following  the 
FOR  (FOR  statement).  Only  columns  0 and  2 through  ? 
have  meaning. 

Columns  display  the  use  of  various  forms  of  operands 
used  with  the  operators  "+"  and  Columns  10 

tb  .-c.agh  11  are  meaningful,  in  addition  to  the  numbers  1 
and  2,  the  following  codes  have  been  used  for  operand 
forma  in  the  above  matrix: 

A variable 

B variable 

LIT  literal 

E expression 

F function  call 

Same  as  PM,  except  for  the  multiplication  operator. 

Same  as  for  PM  and  M,  except  for  the  division  operator 

Columns  represent  all  forms  of  assignment  statement. 
Only  columns  0 through  6 have  meaning. 

Columns  are  a histogram  of  the  number  of  operators 
appearing  on  the  right-hand  side  of  an  assignment  state- 
ment. As  in  all  histogram  form:;,  25  columns  are 
meaningful  in  addition  to  column  0. 

Columns  are  a histogram  of  the  number  of  operators 
appearing  in  Boolean  expressions  used  within 
IF -statements.  Boolean  forms  used  within  other  state- 
ments are  not  included  (e.g.  within  a WHILE  clause,  in  a 
Boolean  assignment,  etc. ). 

Columns  show  the  use  of  the  comparison  operators  with 
various  specific  forms  of  operand.  Columns. 0 
through  10  are  meaningful. 
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Explanation 

Columns  represent  the  number  o£  labels,  GOTO's  and 
switches.  Only  columns  3 through  3 are  meaningful. 

Columns  are  a histogram  of  the  number  of  arguments 
given  in  a procedure  or  function  call. 

Columns  are  a histogram  of  the  nest  depth  of  FOR-loope. 
Although  25  columns  were  potentially  meaningful,  only 
the  first  4 columns  showed  non-zero  values. 

Columns  are  a histogram  of  the  number  of  statements 
used  within  the  FOR-loop  nest  depths  measured  by 
DO.  DPT. 
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2. 


Examples  of  Raw  Data  Matrix  Output 

The  two  example  programs  below,  while  not  of  the  size  of  most  AED 
or  JOBIAL  J3B  compiler  modules,  do  permit  us  to  present  some  concrete 
and  specific  illustrations  of  come  of  the  compiler  instrumentation.  The  two 
brief  programs  are  virtually  identical,  consisting  for  the  most  part  of  one 
'FOR'  statement  with  two  subordinate  assignments.  In  the  first  program 
the  two  assignment  statements  are  simple;  in  the  second  program  one  of 
the  assignments  involves  somewhat  more  computations.  These  programs 
and  statistics  can  be  examined  below. 

Counters  relevant  to  a particular  statement  type  are  collected  into 
the  array  described  above  and  printed  out  here  in  row  form,  with  each  row 
bearing  its  explanatory  label.  Data  for  the  form  of  the  'FOR'  statement 
appears  in  the  rows  labeled  'FOR',  >L-STEP',  'P.-STEP',  -UNTIL*  and 
'FORMW'.  Column  1 of  the  FOR  row  simply  counts  the  number  of 
•FOR'  statements.  Column  0 of  the  L-STEP,  R-STEP  arrays 
count  the  occurrence  of  the  forms  of  initial  value  and  increment  of  the  step 
variable.  Both  tables  have  counts  of  'l*  in  these  positions  since  both  source 
programs  have  the  same  form  of  the  FOR  statement.  Column  2 of 
the  FOR,  UNTIL,  and  FORMW  rows  have  a •!«,  since  the  UNTIL  form  is 
used,  the  terminating  value  is  a literal  (not  equal  to  1),  and  a BEGIN  follows 
the  DO,  respectively. 

Similarly,  the  assignment  statistics  appear  in  the  row  labeled  'A'; 
in  both  examples  a count  cf  2 appears  in  column  1 which  counts  the  assign- 
ments of  variables.  The  row  labelled  'HIST'  contains  a histogram  of  the 
number  of  operands  in  assignment  statements.  Here,  the  two  examples 
differ  in  since  in  the  first  example  both  assignments  have  only  one  operand, 
whereas  in  the  second  example  one  of  the  assignments  has  five  operands. 

The  reader  is  invided  to  verify  the  remainder  of  the  data  output  by  examining 
the  matrix  description. 

For  each  of  the  two  examples,  the  source  language  is  presented  first, 
followed  by  the  raw  data  matrix  output  produced  by  the  instrumented  compiler. 
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EXAMPLE  1 


BEG  in 


DEFINE  PROCEDURE:  MAIN  TOBE 
BEGIN 

INTEGER  A.B.C  : 

INTEGER  ARRAV  0<10>,E<10> 
BOOLEAN  Z ; 

FOR  A = 1 STEP  1 UNTIL  10 
DO  BEGIN 
A *=  B ; 

A = c ; 

END  ; 

END 
END  FI MI 


H 


MAIN 

IF 

ELSE 

FOR 

L-STEP 

R-STEP 

UNTIL 

FORNIJ 

PM 

M 

D 

A 

HIST 
BOOL 
, EQL 
GEO 
GRT 
LEO 
LES 
NEQ 
ANO 
OR 

LBL,GOTO 
PROC 
DO. DPT 
DO.  ST A 


% 


EXAMPLE  2 


BEGIN 


DEFINE  PROCEDURE  MAIN  TOBE 
BEGIN 

INTEGER  R,B,C  ; 

I NTE6ER  fiRRfiV  D < 1 0>  , E < 1 0 > 
BOOLEAN  r.  ; 

FOR  ft  = 1 STEP  1 UNTIL  10 
DO  BEGIN 

ft  = 8*B+C*C+10  ! 

ft  = c ; 

END  ; 

END 
END  FINI 


MAIN 

IF 

ELSE 

FOP 

L-STEP 

R-STEP 

uhtil* 

FORHW 

PM 

II 

0 

ft 

HIST 

BOOL 

EQL 

OEO 

GRT 

LEQ 

LES 

HEO 

ftHO 

Oft 

L6L.G0T0 
PROC 
00. OPT 
DO.STft 


3. 


Dynamic  Raw  Data 

In  order  to  weigh,  the  static  data  based  upon  the  sample  test  runs, 
two  additional  special  compiler  versions  were  constructed  (one  for  AED  and 
one  for  J3B)  which  output  statistics  showing  how  many  times  each  compiler 
procedure  was  entered  during  the  test  run.  Samples  of  the  raw  data 
obtained  by  these  means  is  given  below.  In  each  case,  only  the  first  page  of 
output  is  presented  as  a sample,  whereas  the  actual  output  included  about 
8 pages  for  each  compiler.  The  first  example  page  of  data  is  from  the  AED 
compiler,  and  the  second  is  from  the  J3B  compiler. 
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AED 

PROCEDURE  CALLS  STATISTICS  AT  EXIT  FROM  PHASES 

NUMBER  OF  PROCEDURES  TRACED  = 380 

NUMBER  UF  CALLS  TRACED  :-  10327c: 

NUMBER  OF  NORMAL  RETURNS  = 35933 


MAIN 

AT  location 

12000  CALLED 

1 5 RETURNED 

0 

AED1MI T 

AT  LUCH  r I ON 

1ESFS  CALLED 

1 , RETURNED 

1 

AED I Ml 

AT  LOCATION 

1CC2S  called 

1 , h:E  TURNED 

1 

COMARG 

H i LUCAriON 

18oB8  CHILLED 

4, RETURNED 

4 

PHASE 1 

llT  LOCUTION 

30 330  CALLED 

1 1.  RETURNED 

1 

FSET 

1-1 T LOCATION 

1 c-C-40  CALLED 

1 « RETURNED 

1 

FGSMEM 

AT  location 

1 3848  CALLED 

128* RETURNED 

128 

FREMEM 

ht  location 

1CD3S  CALLED 

1 23 , RETURNED 

128 

FRET 

Hf  location 

1 709C  CALLED 

1504, RETURNED 

1504 

FRED 

Hi  LOCATION 

1SB18  CHLLED 

13* RETURNED 

19 

SHORTS 

Hi  LOCATION 

1 4D4S  CHLLED 

1 > RETURNED 

1 

SETsPL 

HT  LOCATION 

23D4S  CALLED 

1 * RETURNED 

1 

CEOLS 

Ht  LOCATION 

2B640  CALLED 

14* RETURNED 

14 

COMPAR 

ht  location 

2C-D38  CHLLED 

18* RETURNED 

0 

SETNMs 

at  location 

27A4S  CALLED 

1 » RETURNED 

1 

INTPH1 

ht  location 

2 56 AO  CALLED 

1 > RETURNED 

1 

SETFIRS 

AT  LOCATION 

1 £634  CALLED 

2* RETURNED 

o 

c 

3ETSTK 

Hi  LOCATION 

223F4  CHLLED 

1 , RETURNED 

1 

SETRMK 

AT  location 

21S5C  CALLED 

1 * RETURNED 

1 

SHRTSP 

Hi  LOCATION 

1 4DCh  CALLED 

2710, RETURNED 

2710 

FREC 

AT  LOCATION 

1 t-DDC  CALLED 

27 IS,  RETURNED 

2718 

FREE 

HT  LOCATION 

1 SECS  CALLED 

23S8, RETURNED 

£983 

SETCHR 

HT  LOCATION 

24360  CALLED 

1 , RETURNED 

1 

SETITM 

AT  LOCATION 

2A3FS  CALLED 

1 , RETURNED 

1 

TAROT  2 

AT  LOCATION 

21DS0  CHLLED 

1 , RETURNED 

1 

COPVC 

AT  LOCATION 

1 DOFS  CALLED 

24, RETURNED 

24 

TAROTS 

HIT  LOCATION 

26HB0  chilled 

i , RETURNED 

1 

HOST  1 

rlT  LOCATION 

15928  CALLED 

1 , RETURNED 

1 

ISITEM 

i-1  T LOCATION 

2 7E24  CALLED 

7, RETURNED 

7 

STATE 

AT  LOCAT 1 UN 

2ESA8  CHLLED 

7, RETURNED 

7 

INSERT 

HT  location 

1E3DC  CALLED 

3 14, RETURNED 

914 

ROT  C 

A 1 LOCATION 

142 1C  CALLED 

383, RETURNED 

989 

S. SEARC 

HT  LOCATION 

c'3F30  CALLED 

13, RETURNED 

1 

S.  I.OPV 

HT  LOCATION 

24100  CALLED 

12, RETURNED 

12 

S.RHEXT 

AT  LOCUTION 

2 3E20  CHLLED 

12, RETURNED 

12 

S.SHEXT 

riT  LOCATION 

23ED8  CALLED 

2‘‘ , RETURNED 

24 

PASS! 

HIT  LOCAT  I ON 

249AS  CALLED 

J , RETURNED 

1 

INTRPE 

rlT  LOCATION 

13E74  CALLED 

4, RETURNED 

4 

GENRE 

hT  LUChTION 

2D 190  CALLED 

J, RETURNED 

r* 

V 

FREE 

AT  LOCATION 

16D1C  CALLED 

22c, RETURNED 

226 

RESET 

AT  LOCATION 

2476C  CALLED 

i. , RETURNED 

1 

I ii I T i A 

hT  LOCATION 

i*5CS  CALLED 

1 , RETURNED 

1 

I . sEARC 

hT  location 

14940  CALLED 

95a, RETURNED 

oo  1 

I . COPY 

ht  LOCATION 

1475C  CALLED 

*53, RETURNED 

o53 

I.RFIRS 

hT  LOCATION 

145F8  CHLLED 

1S2, RETURNED 

154 

IDENT 

HT  location 

1B888  CALLED 

297, RETURNED 

297 

t 


m 
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J33 


& 

X* 

PROCEDURE  CALLS 

STATISTICS  at  exit 

FROM  P.EACS 

f 

number 

OF  PROCEDURES 

traced  = 2Sb 

1 

number 

OF  CALLS  TRACED  = 116&00 

1 

1 

!*' 

number 

OF  NORMAL  RETURNS  * 116461 

£ 

?( 

MAIN 

AT  LOCATION 

1464C  CALLED 

1 .RETURNED 

0 

F 

aeoinit 

AT  LOCATION 

SbAJB  CALLED 

1 tRETURNEO 

1 

! 

AEDlNl 

AT  LOCATION 

5C4/0  CALLED 

1 .returned 

1 

i 

T.COMP 

AT  LOCATION 

27R9C  CALLED 

i .returned 

1 

U.IDaT 

at  location 

27F4C  CALLED 

1 « RE  turned 

1 

t 

fremem 

AT  LOCATION 

56 1 bo  CALLED 

1 .RF TURNED 

1 

| 

OETMfM 

AT  LOCATION 

19F9**  CALLED 

i .returned 

1 

I. Fit 

at  location 

22964  CALLED 

i .returned 

1 

i 

n.iNTP 

at  location 

127AC  CALLED 

2 » returned 

2 

GFNRH 

AT  LOCATION 

53D00  CALLED 

1 .RETURNED 

1 

ft 

l 

s 

U.FREZ 

AT  LOCATION 

1A9B4  CALLtD 

Ulb.RETURNED 

1415 

i 

u.frff 

AT  LOCATION 

1ASPR  CALLED 

1*27. RETURNED 

1827 

j 

U.FHLP 

at  location 

19F44  CALLtD 

/.returned 

7 

i 

r 

U.FHfT 

AT  LOCATION 

ia/ao  called 

1790. RETURNED 

1790 

;* 

OPNFIL 

AT  LOCATION 

S3F0C  CALLED 

/♦returned 

7 

i 

rpopen 

AT  LOCATION 

bOFbB  CALLED 

1 1 .RETURNED 

1 1 

^ 

•2 

makefl 

AT  LOCATION 

59FFH  CALLED 

1 1 .RETURNED 

11 

i 

rdwrop 

AT  LOCATION 

SA0D4  CALLED 

11. returned 

11 

IS 

OPNDSK 

AT  LOCATION 

599AC  CALLED 

11. RETURNED 

11 

B 

t 

COPY  C 

AT  LOCATION 

52?20  CALLED 

12. RETURNED 

12 

. 

? 

OPNCmS 

AT  LOCATION 

5D4F0  CALLED 

11. RETURNED 

11 

* 

r> 

4 

% 

IJ.FWFC 

at  location 

1A46C  CALLED 

20. RETURNED 

?n 

i 

SFTFmT 

AT  LOCATION 

SA?2C  CALLED 

1 1 .returned 

11 

s 

J 

PUSH.FI 

AT  LOCATION 

S.1F64  CALLED 

7 .RETURNED 

7 

t 

SPSITM 

at  location 

54QOO  CALLED 

14. RETURNED 

14 

V 

F .OPTS 

AT  LOCATION 

2730c  CALLED 

1 .returned 

1 

r 

> 

C0MAR6 

AT  LOCATION 

5bF90  CALLED 

1 .returned 

1 

* 

V 

U.SCDA 

AT  LOCATION 

IA004  CALLtD 

1 .RETURNED 

1 

V 

TfPHOO 

AT  LOCATION 

27724  CALLtD 

1 .returned 

1 

4 

I. LEX 

AT  LOCATION 

1 b A84  CALLED 

1 .returned 

1 

| 

GETHmS 

at  location 

bJSDH  CALLED 

2 .RETURNED 

2 

► 

T.Ph'R? 

AT  LOCATION 

1 bF7C  CALLED 

1 .RE  TURNED 

) 

f j 

F. TITLE 

AT  LOCATION 

1 *♦  ?6  0 CALLtD 

1 .rfturned 

1 

LINES. 

at  location 

1 4 0 K C CALLED 

1 .returned 

1 

| j 

SFTUUT 

AT  LOCAT  JON 

53680  CALLED 

i.returned 

1 

I. TARS 

AT  LOCATION 

1B164  CALLED 

1 .returned 

1 

i i 

I.COmD 

AT  LOCATION 

279b4  CALLtD 

9. RFTURnFD 

O 

r 

I>  r 

F f 

f 

A , 

\ 1 

L .CSYM 

at  location 

2'QDC  CALLED 

i .rfturned 

1 

I..LOOS 

AT  LOCATION 

1 6Dt  4 CALLtD 

62. RFTURNED 

62 

I..UHAS 

AT  LOCATION 

16CF4  CALLtD 

1 199. RFTURNED 

1199 

f i 

l.fnos 

AT  LOCATION 

16414  CALLED 

3106. RETURNED 

3106 

348 
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MISSION 

of 

Rome  Air  Development  Center 


RADC  is  the  principal  AFSC  organization  charged  with 
planning  and  executing  the  USAF  exploratory  and  advanced 
development  programs  for  electromagnetic  intelligence 
techniques , reliability  and  compatibility  techniques  for 
electronic  systems,  electromagnetic  transmission  and 
reception,  ground  based  surveillance,  ground 
communications , information  displays  and  information 
processing.  This  Center  provides  technical  or 
management  assistance  in  support  of  studies,  analyses, 
development  planning  activities , acquisition,  test, 
evaluation,  modification,  and  operation  of  aerospace 
systems  and  related  equipment. 


Source  AFSCR  23-50,  11  May  70 


